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I.  INTRODUCTION 


A.  PURPOSE 

While  operational  eapabilities  are  used  to  determine  requirements  doeuments  for 
eombat  systems,  the  aequisition  proeess  must  take  into  aeeount  eosts  and  sehedule  when 
providing  these  systems  to  the  Fleet.  Information  teehnology  systems  are  subsequently 
measured  through  an  analysis  of  return  on  investment,  utilizing  a  monetary  me  trie.  This 
analysis  of  return  does  not  adequately  aeeount  for  the  value  the  system  ean  provide  to  the 
operator,  nor  does  it  aeeount  for  any  additional  effieieneies  that  eould  be  ineorporated  in 
future  designs.  Operational  value  should  not  be  measured  only  through  eost  savings, 
return  on  investment  or  finaneial  metrics,  but  rather  the  additional  capabilities  that  are 
leveraged  through  the  application  of  IT.  A  tactical  operator  does  not  value  a  system  by 
how  much  it  cost,  or  if  it  will  produce  a  financial  return  on  investment,  but  rather  whether 
the  system  can  provide  a  more  timely  and  efficient  means  to  accomplish  the  mission. 

The  purpose  of  this  research  is  to  determine  if  a  knowledge  value-added  (KVA) 
methodology  can  measure  the  operational  value  of  a  system,  and  where  deficiencies  can 
be  identified  and  processes  improved  to  provide  a  more  robust  and  capable  information 
technology  system  to  the  war  fighter.  A  current  initiative  known  as  Navy  Open 
Architecture  (OA)  seeks  to  leverage  commercial  technology,  non-proprietary  standards 
and  software  reuse  to  reduce  multiple  architectures  and  improve  interoperability.  A 
realization  of  this  initiative  may  provide  huge  dividends  through  implementing  an 
approach  to  development  of  situational  awareness  systems  aboard  naval  vessels.  Open 
architecture  is  predominantly  associated  with  providing  more  capabilities  in  the  design 
and  maintenance  of  information  technology  systems,  and  budgetary  constraints  with 
systems  design  and  development. 

B.  BACKGROUND 

Track  management  is  the  process  by  which  friendly  and  enemy  forces  are 
detected,  identified,  monitored  and  updated  and  communicated  throughout  the  area  of 
operations.  This  is  a  fundamental  capability  that  is  inherent  in  all  naval  ships  to  some 
extent. 
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Historically,  track  management  was  conducted  through  the  use  of  grease  pencils 
and  wall  charts.  As  advances  in  teehnology  increased,  automation  through  information 
teehnology  beeame  the  norm.  With  the  advent  of  the  AEGIS  platform,  multiple  sensors 
and  data  links  were  fused  to  provide  a  eomprehensive  situational  awareness  of  all  tracks 
within  a  given  area  of  responsibility  (AOR).  While  the  AEGIS  system,  and  later  SSDS, 
platforms  significantly  enhanced  the  track  management  capabilities  of  surface  ships,  they 
were  created  based  on  a  proprietary  architeeture  which  was  characterized  by  stovepipe 
systems  that  were  neither  sealeable  nor  interoperable.  Open  architecture  provides  a 
means  to  propel  the  Navy  into  the  next  century  and  an  era  of  joint  interoperability. 

In  an  era  where  teehnological  development  outpaces  the  current  proeurement 
proeess,  the  United  States  Navy  must  implement  a  strategy  that  will  enable  operational 
capabilities  to  remain  at  the  forefront  of  naval  warfare.  Current  legaey  systems  utilizing 
a  closed,  proprietary  architeeture  in  hardware  and  software  greatly  limit  operational 
eapabilities  that  could  be  generated  through  interoperability  and  collaborative  proeesses 
that  eurrent  technology  can  provide.  “Stovepipe”  systems  built  are  difficult  to  upgrade 
and  provide  limited  interoperability  with  other  systems.  As  technology  continues  to 
define  requirements  for  combat  effectiveness,  the  operational  forces  are  required  to 
eontinue  to  keep  up  with  a  multitude  of  systems  that  are  woefully  inadequate  in  the  realm 
of  interoperability  and  functionality. 

The  key  to  United  States  dominanee  in  any  eonfiict,  as  discussed  by  the  Chairman 
of  the  Joint  Chiefs  of  Staff  in  Joint  Vision  2020,  will  be  “decision  superiority.”  Decision 
superiority  can  be  defined  as  “translating  information  superiority  into  better  decisions 
arrived  at  and  implemented  faster  than  an  enemy  can  react.”  To  achieve  information 
superiority,  the  Department  of  Defense  has  been  engaged  in  the  development  of  a  Global 
Information  Grid  (GIG)  which  will  provide  the  environment  for  deeision  superiority.  As 
the  Department  of  Defense  continues  to  strive  for  a  more  joint  operational  environment, 
the  United  States  Navy  will  need  to  develop  architectures  to  meet  the  integration 
challenges  that  will  be  required  for  integration  into  the  Global  Information  Grid. 

C.  RESEARCH  OBJECTIVES 

The  objective  of  this  researeh  is  to  analyze  the  AEGIS  and  SSDS  traek 

management  systems  to  determine  potential  operational  benefits  that  eould  be  realized 
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through  the  application  of  an  OA  approach  to  system  design.  Through  an  application  of  a 
knowledge  value-added  methodology,  knowledge  assets  inherent  in  the  core  processes  of 
a  system  can  be  identified,  quantified  and  subsequently  valued. 

The  methodology  provides  a  return  on  knowledge  or  ROK  (a  ratio  which 
measures  the  knowledge  assets  resident  in  a  system  through  its  decomposition  into  the 
common  units  of  output  the  knowledge  asset  produces).  This  commonality  can  then  be 
used  in  the  assessment  of  multiple  systems  within  a  common  domain. 

D,  RESEARCH  QUESTIONS 

There  are  no  current  measurements  or  metrics  that  can  effectively  provide  a 
defensible  return  on  investment  estimate  at  the  sub  corporate  level  with  regards  to  a 
system’s  operational  value.  Current  methodologies  are  applicable  to  procurement, 
maintenance  and  lifecycle  costs,  but  are  insufficient  when  determining  actual  value  of  a 
system  to  an  operator. 

This  research  study  will  provide  insight  into  whether  OA  can  improve  operational 
value  in  a  situational  awareness  system.  Of  interest  will  be  whether  1)  KVA  can  be 
applied  to  estimate  the  value  of  the  current  track  management  systems  on  the  AEGIS  and 
SSDS  platforms,  2)  the  resulting  ROK  can  be  used  to  determine  areas  where  OA  may 
provide  increased  efficiency,  and  for  future  research  3)  real  options  analysis  can  be  used 
to  support  decisions  regarding  functional  integration  of  current  platforms  into  future 
systems.  These  questions  will  be  analyzed  using  the  KVA  and  Real  Options 
methodologies  to  address  these  issues. 

E.  METHODOLOGY 

This  thesis  will  model  the  current  track  management  processes  found  within  both 
the  AEGIS  and  SSDS  platforms  and  apply  the  KVA  methodology  to  them  in  order  to 
determine  an  “As  Is”  process  performance  baseline.  The  processes  for  the  current 
systems  will  be  derived  from  process  flow  diagrams,  use-case  diagrams,  interviews  with 
subject  matter  experts  (SME)  and  literature  review  of  pertinent  documents.  The  resulting 
return  on  knowledge  will  be  analyzed  from  an  operational  perspective  with  respect  to  a 
“To  Be”  process  generated  from  an  OA  design. 
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Both  the  “As  Is”  and  “To  Be”  proeess  analysis  will  be  eondueted  utilizing  the 
“learning  time”  approaeh  to  KVA  (explained  later  in  this  thesis).  The  eore  elements  of 
“time-to-learn”,  “number  of  personnel  involved”,  and  “times  fired”  will  produce  a  ratio 
of  the  performance  of  knowledge  assets  in  each  process.  This  ratio  (ROK)  provides  a 
common  unit  of  measurement  to  generate  the  numerator  (i.e.,  value  estimate),  and  is  used 
subsequently  for  each  sub  process  within  the  track  management  process. 

F.  SCOPE 

The  scope  of  this  thesis  will  be  limited  to  the  operational  value  that  OA  can 
provide  to  the  Fleet  with  respect  to  the  situational  awareness  process.  Though  greater 
value  from  open  architecture  may  be  in  its  labor  saving  and  cost  saving  attributes  for 
acquisition  and  maintenance,  this  research  is  focused  on  the  knowledge  capital  inherent 
in  the  current  systems  and  how  an  understanding  of  this  can  provide  insight  into  future 
efficiencies  based  on  an  OA  approach  to  systems  development  at  the  operator  level. 

G.  THESIS  ORGANIZATION 

This  thesis  will  be  organized  in  the  following  manner: 

Chapter  I  will  provide  an  overview  of  the  thesis  with  regard  to  purpose  and  scope. 
Additionally,  research  questions  and  objectives  will  be  provided,  along  with  the 
methodology  used  to  generate  the  final  conclusions.  Chapter  II  is  provided  for  a 
background  understanding  of  open  architecture,  how  the  concept  is  applied  within  the 
Navy,  and  how  it  may  be  applied  to  the  research.  This  chapter  provides  the  foundation 
for  the  information  needed  to  complete  the  research  and  draw  conclusions.  Chapter  III 
outlines  the  KVA  methodology  so  as  to  provide  a  basic  understanding  of  the  concept  of 
knowledge  capital  and  how  return  on  knowledge  is  derived.  Chapter  IV  is  a  detailed 
synopsis  of  the  research  conducted,  findings  and  KVA  analysis.  This  chapter  is  the  crux 
of  the  thesis  and  puts  the  other  chapters  into  operational  perspective.  Chapter  V  presents 
conclusions,  real  options  analysis  and  any  recommendations  to  the  Navy  that  may  be 
derived  from  the  research. 
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II.  OPEN  ARCHITECTURE  ENVIRONMENT 


A.  GENERAL 

The  Government  Aeeountability  Offiee  (GAO)  reeently  addressed  the  inadequaey 
of  legacy  systems  within  the  Department  of  Defense  (DOD)  with  regard  to 
interoperability:  “Despite  recent  progress  by  the  Department  of  Defense,  military 
operations  continue  to  be  hampered  by  command,  control,  and  communications  systems 
that  lack  the  ability  to  interoperate”  (GAO-06-21 1,  2006).  The  report  further  noted  that 
“rather  than  being  developed  around  integrated  architectures  and  common  standards, 
systems  have  been  designed  and  developed  using  different  standards  and  protocols” 
(GAO-06-211,  2006),  which  limits  their  interoperability  and  ability  to  exchange 
information  horizontally  vice  vertically.  With  the  inception  of  “Sea  Power  21”,  the  Chief 
of  Naval  Operations  (CNO),  Admiral  Vernon  Clark,  stated  that  “...future  naval 
operations  will  use  revolutionary  information  superiority”  {Proceedings,  2002).  The  idea 
of  information  superiority  was  to  be  achieved  through  the  application  of  FORCEnet, 
which  is  “an  overarching  effort  to  integrate  warriors,  sensors,  networks,  command  and 
control,  platforms  and  weapons  into  a  fully  netted,  combat  force.”  This  issue  was 
addressed  in  2003  by  Vice  Admirals  Richard  Mayo  and  John  Nathman  in  a  Proceedings 
article  regarding  the  FORCEnet  architecture  whereby  they  commented  on  “...standard 
joint  protocols,  common  data  packaging,  seamless  interoperability,  and  strengthened 
security”  {Proceedings,  2003)  as  requirements  for  FORCEnet  to  become  an  enabler  of 
Sea  Power  21.  To  accomplish  these  tasks,  the  Navy  must  adhere  to  an  open  architectural 
framework  which  will  enable  effective  interoperability  and  scalability  required  of  the 
Global  Information  Grid  (GIG)  and  net  centric  warfare. 

These  new  visions  permeated  the  U.S.  Navy  and  resulted  in  the  creation  of  the 
Program  Executive  Office,  Integrated  Warfare  Systems  (PEO  IWS)  in  2002.  This  office 
is  charged  with  implementing  the  Navy’s  Open  Architecture  (OA)  strategy  through  the 
adoption  of  standards,  products  and  best  practices  to  ensure  that  future  surface  and 
submarine  combat  systems  will  allow  for  integration  and  future  technological  insertion. 
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B.  DEFINING  OPEN  ARCHITECTURE 

Open  architecture,  as  defined  by  the  Open  Systems  Joint  Task  Force  (OSJTF)  is 
one  “that  employs  open  standards  for  key  interfaces  within  a  system”,  where  open 
standards  are  ones  which  “are  widely  used,  consensus  based,  published  and  maintained 
by  recognized  industry  standards  organizations”,  and  key  interfaces  are  “common 
boundaries  shared  between  system  modules  that  provides  access  to  critical  data, 
information,  materiel,  or  services;  and/or  are  of  high  interest  due  to  rapid  technological 
change,  a  high  rate  of  failure,  or  costliness  of  connected  modules”  (www. 
http://www.acq.osd.mil/ositiytermsdef.html).  With  this  concept  in  mind,  the  Navy’s 
surface  ship  community  defined  OA  as  “a  system  architecture  and  the  architectural 
components  of  a  system  that  conform  to  open  system  standards  and  possess  the  other 
open  systems  attributes”  (OACE  Guidance  Document). 

1,  OA  Attributes 

An  open  architecture  framework  should  provide  principles  and  guidelines  which 
will  enable  open  systems  to  be  designed  and  evolved  over  the  course  of  their  life  cycle. 
To  accomplish  this,  open  architecture  provides  a  core  group  of  concepts  that  must  be 
addressed  in  order  to  achieve  mission  requirements.  These  concepts,  while  not  all 
encompassing,  provide  the  foundation  for  the  open  architecture  framework. 
a.  Modularity 

One  of  the  underpinnings  of  an  open  architecture  is  the  adherence  to 
modularity,  or  modular  programming.  This  concept  is  characterized  by  the 
decomposition  of  a  system  into  smaller  subsystems,  or  components,  which  are 
independently  operable,  subject  to  change  and  provide  for  interaction  with  each  other 
through  interfaces.  These  components,  each  with  their  own  set  of  independent 
characteristics,  perform  specific  functions  for  the  system  and,  upon  completion,  return 
control  back  to  the  system.  Each  of  these  components  can  be  developed,  tested  and 
upgraded  independently,  enabling  greater  functionality  within  the  entire  system.  This 
concept  is  represented  in  Eigure  1.  Modularity  lends  itself  to  software  reuse  which  is  also 
considered  to  be  vital  in  an  open  architecture  environment. 
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Figure  1.  Modular  Design  Model 
b.  Reuse 

Segments  of  code  that  provide  defined  functionality  (command  and 
control,  sensor  control,  track  identification  etc.)  which  can  be  catalogued  and  reused  over 
multiple  platforms  (AEGIS,  SSDS  etc.)  provide  greater  flexibility  in  creation  and 
maintenance  of  application  software.  The  analogy  one  might  use  would  be  in  the 
assembly  of  an  automobile.  The  auto  (system)  needs  multiple  parts  (components)  which 
are  broken  down  by  functional  capabilities  (fuel  system,  brake  system,  cooling  system 
etc.).  When  one  desires  to  build  the  auto,  they  need  only  go  to  the  parts  store  and 
purchase  the  required  parts  and  assemble  them  together  to  create  the  finished  product. 
The  same  holds  true  for  software  reuse:  Libraries  of  components,  or  segments  of  code, 
are  created  and  maintained  so  that  they  may  be  retrieved  and  used  in  the  creation  of  new 
systems  that  require  the  specific  functionality  that  the  components  provide.  Generic  and 
functionally-specific  components  can  be  mixed  and  matched  without  undermining  the 
overall  design  of  the  system,  nor  impeding  the  overall  functionality  of  the  system. 
Through  the  partitioning  of  components  along  functional  boundaries  and  reuse,  systems 
can  be  designed  more  efficiently,  thereby  reducing  lifecycle  costs  and  development  time. 
Though  this  attribute  seems  to  be  strictly  technical,  component  reuse  is  determined 
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through  business  case  evaluation,  programmatic  decisions  and  technical  feasibility, 
ensuring  that  the  operators  of  a  system  have  input  into  its  development. 

c.  Scalability 

Within  an  OA  framework,  scalability  implies  the  ability  of  a  system  to 
accommodate  new  functionality  and  resources  without  major  change  or  modification. 
The  idea  of  increasing  users,  workload  or  amount  of  transactions  without  affecting  the 
current  operation  of  the  system  is  a  large  part  of  an  open  architecture  framework. 
Through  adding  computing  components;  upgrading  current  computing  components;  or 
providing  a  technology  refresh  of  current  computing  components,  new  functional 
capabilities  can  be  provided  without  disrupting  current  capabilities  so  that  continuity  of 
work  can  be  achieved.  This  concept  is  imperative  to  the  operational  value  of  a  system. 

d.  Portability 

Portability  speaks  to  the  idea  that  applications  can  be  easily  moved  from 
one  hardware  or  software  platform  to  another.  Due  to  increasing  and  rapid  advances  in 
technology,  it  is  imperative  that  application  source  code  is  able  to  transition  between 
multiple  operating  systems,  commercial  hardware,  networks  and  middleware.  If  an  open 
architecture  is  to  be  adhered  to,  applications  must  have  built  in  capabilities  for  seamlessly 
switching  between  a  multitude  of  hardware  and  software  platforms.  Additionally, 
portability  can  be  defined  as  the  ability  of  the  user  to  transition  from  one  system  to 
another  similar  system  with  minimal  training.  While  user  portability  is  not  widely 
thought  about,  it  does  have  implications  in  the  operational  context  of  a  system.  Table  1 
provides  a  listing  of  possible  strategies  for  implementing  portability  in  an  application. 
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Method 

Definition 

Usage 

Benefits 

Comments 

Standards 

Use  of  widely  recognized 
standards  (e.g.  international)  to 
ensure  application  portability 

Basis  for  many 
systems 

Many  vendors  and 
products 

OSJTF  endorsed 

Standards  do 
change  slowly, 
must  be  tracked 

Widely  used 
products 

Use  of  commonly  available  non¬ 
standard  products,  e.g.  Microsoft 

Widespread  in 
practice,  often 
business -based 

Readily  available 
products 

OSJTF  2™*  choice 

Vendor  lock 
Market  captive 
Must  upgrade 

Porting 

Moving  applications  from  one  set 
of  technology  products  to  another 
(e.g.  OS,  M/W)  by  changing  APIs 
within  applications 

Often  used  to 
move  from  non¬ 
standard  basis 
to  standards 

Low  or  no  cost  if 
porting  within 
standards  family 

Not  all  products 
exactly  match 
standards 

Virtual 

machine 

Run-time  interpreter  of  machine 
independent  version  of  source 
code  (e.g.  Java  byte  code) 

Widely  used 
with  popular 

Java  language 

Portable  code 

Not  good  for 
real-time  apps 

Wrappers 

Software  layer  that  hides  a  variety 
of  products  below  and  exports  a 
common  interface  to  applications 

Used  to  hide 

non-standard 

products 

Low  cost  within 
domain  of  use 

Vendor  lock 

Slows  migration 
to  standards 

Emulation 

Software  layer  that  makes  one  type 
of  computer  appear  to  be  another 
type  by  “emulating”  the  missing 
computer’s  instructions 

May  be  used  for 
legacy  and 
obsolescent 
systems 

Software  does  not 
have  to  change  to 
new  computer 
type 

Overhead 

Architectural 

obsolescence 

Model  Driven 
Architecture 

Use  of  highly  abstracted  modeling 
tools  (e.g.  UML)  for  design;  source 
code  generated  automatically 

Not  yet  widely 
used  but  holds 
great  promise 

Hides  details 

May  enable  auto 
code  generation 

Still  maturing 

‘  Pr:mariiy  addresses  DO'tabcirty  across  operatng  system  and  middleware  products:  modem  processors  a^e  largely  (but  not  completely)  aost'acted  by  OS  & 
Thus,  portability  at  OS  &  NiW  level  suppois  p'‘ocessor  &  hardware  independence. 


Table  1.  Application  Portability  Strategies  (OACE  Design  Guidance  1.0,  August 

2004) 

2,  OA  Benefits 

A  comparison  of  open  systems  and  closed  or  proprietary  systems  is  presented  in 
Table  2. 
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Closed  S>  stem  Characteristics 

Open  Si  stem  C  haracteristics 

Use  of  closely  held,  private  interfaces, 
languages,  data  formats  and  protocols 
(goveniment  or  vendor  luiique  standards) 

Use  of  pubhcly  available  and  widely  used 
mterfaces.  languages,  data  fomiats  and 
protocols 

critical  miportance  is  gn  en  to  luiique  design 
and  m^lementation 

critical  miportance  is  given  to  mterfaces 
management  and  widely  used  conventions 

less  emphasis  on  modulann' 

heaiy  emphasis  on  modulann’ 

vendor  and  teclinolog\’  dependency 

vendor  and  technolog\’  mdependence 

mmuiiization  of  the  niuuber  of 
ui^lementations 

mumiiization  of  the  nimiber  of  npes  of 
mterfaces 

difficult  and  more  costly  integration 

easier  and  more  cost  effective  integration 

diflficuln'  with  portabihw,  connectinry 
mteroperabihn-  and  scalabiliW 

high  degree  of  portabihn,',  connecti\in% 
mteroperabihn-.  and  scalabihn- 

use  of  sole-source  vendor 

use  of  multiple  vendors 

expansion  and  upgraduig  usually  reqmres 
considerable  tune,  monev  and  effort 

easier,  qiucker  and  less  expensive  expansion 
and  upgradmg 

higher  total  owiierslup  cost 

lower  total  ownership  cost 

slower  and  more  costly  technologi'  transfer 

technologi’  transfer  is  faster  and  less  costly 

components,  mterfaces,  standards,  and 
unplementations  are  selected  sequentiallv 

components,  mterfaces.  sttuidards,  and 
miplementations  are  selected  interactivelv 

systems  w  ith  shorter  hfe  eiqiectancy 

systems  with  longer  life  expectancy 

use  of  mdividual  company  preferences  to  set 
and  mauitam  specifications 

use  of  group  consensus  process  to  mamtam 
mterface  specifications 

less  adaptable  to  change  m  threats  and 
teclmologies 

more  adaptable  to  evolving  threats  and 
technologies 

focusmg  mostly  on  development  cost  and 
meeting  present  mission 

focusmg  on  total  costs  of  ownership, 
sustaimnent.  and  growth 

user  as  the  producer  of  svstems 

user  as  the  consiuner  of  components 

rigid  and  slow  system  of  influence  and 
control 

real  time  and  cybernetic  system  of  mfluence 
and  control 

adversanal  relationship  with  pmue 
contractors  supphers  vendors 

Svnibiotic  relationsliip  with  prune 
contractors  supphers.  vendors 

mostly  confined  to  traditional  supphers 

non-traditional  supphers  can  compete 

single  confomiance  testing 

verv-  cliallengmg  conformance  testing 

Table  2.  Open  versus  Closed  systems  (The  Test  and  Evaluation  Challenges  of 
following  an  Open  System  Strategy”  by  Cyrus  H.  Azani) 

An  OA  approach  to  systems  development  can  produce  a  multitude  of  benefits  that 
encompass  a  wide  range  of  areas,  from  acquisitions  to  operations.  A  few  of  these 
benefits  are  discussed  as  they  pertain  to  naval  combat  systems: 

•  Lower  life  cycle  cost  for  weapon  systems:  Total  cost  of  ownership  will  be 
decreased  due  to  increased  maintainability,  interoperability  and 
upgradeability. 
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•  Better  performing  systems:  The  ability  to  rapidly  upgrade  hardware  and 
software  with  the  latest  technology  enables  greater  capabilities, 
efficiencies  and  interoperability. 

•  Improved  interoperability  for  joint  war  fighting:  The  concept  of  software 
reuse  and  modularity  facilitates  interoperability  between  systems  that  use 
an  open  architecture  framework. 

•  Closer  cooperation  between  commercial  and  military  electronics 
industries:  Moving  away  from  proprietary  systems,  where  competition 
becomes  obsolete  enables  a  broader  range  of  ideas  and  technological 
solutions  to  be  presented.  When  systems  are  open,  the  collaborative 
efforts  provide  for  a  more  functional  and  capable  system. 

In  an  operational  environment,  benefits  of  open  architecture  can  be  manifested  in 
a  multitude  of  ways.  Of  primary  focus  is  the  interoperability  of  systems.  When  systems 
are  designed  in  a  proprietary,  or  closed,  manner  they  are  not  effectively  integrated  into 
current  systems,  nor  are  upgrades  or  insertion  of  new  technology  easily  accomplished. 
Many  times  additional  “middleware”  must  be  used  so  that  interoperability  can  be 
achieved  (middleware,  for  this  purpose,  is  software  that  connects  two  disparate  and 
closed  systems  together  through  the  use  of  defined  interfaces).  When  systems  use  an  OA 
approach,  the  interoperability  problem  can  be  rectified.  The  outcome  for  the  operator 
could  possibly  be  decreased  training  time  required  for  the  systems;  decreased  “touch 
time”  on  processes  through  automating  what  was  normally  a  manual  process;  and 
increased  efficiency  through  seamless  integration  of  multiple  systems.  The 
interoperability  of  multiple  applications  enables  systems  to  be  more  robust,  which  in  turn, 
facilitates  more  capable  systems. 

Operators  always  want  more  capable  and  better  performing  systems.  Using  an 
OA  approach  to  system  development  can  make  this  a  reality.  Speaking  on  the  status  of 
legacy  hardware  for  naval  systems.  Captain  Thomas  Strei,  Deputy  Director  for  Open 
Architecture,  PEO  IWS  stated  that  “current  systems  are  operating  at  99%  capacity  in  non- 
stressed  environments”  (Strei,  2003).  Upgrades  that  would  facilitate  greater  processing 
capacity,  increased  data  sharing  capabilities  and  communication  are  unable  to  be 
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performed  without  eompletely  overhauling  the  current  systems.  With  an  open 
architecture  approach,  hardware  and  software  can  be  modularized,  making  upgrades  more 
efficient  and  timely.  Commercial-off-the-Shelf  (COTS)  technology  and  equipment  is 
maximized  to  the  fullest  extent,  thereby  migrating  away  from  proprietary  hardware  and 
software  to  a  more  robust  architecture  that  takes  advantage  of  commercial  advances. 
This  idea  enables  the  most  current  technology  to  be  integrated  into  the  system,  facilitating 
faster,  more  efficient  systems  at  the  disposal  of  the  operators. 

3,  OA  Limitations 

While  there  are  many  benefits  to  the  use  of  an  OA  approach,  there  are  also  some 
limitations  that  must  be  addressed.  As  risk  analysis  and  mitigation  are  important  factors 
when  determining  an  architectural  approach,  limitations  need  to  be  discussed  at  the  onset 
of  any  program. 

Of  main  concern  is  the  number  of  interfaces  that  may  be  brought  about  by  an  OA 
approach.  The  following  is  an  excerpt  from  the  Committee  on  the  FORCEnet 
Implementation  Strategy  regarding  systems  engineering  strategies  for  FORCEnet:  “The 
number  of  unique  interfaces  that  must  be  maintained  needs  to  be  carefully  selected  and 
kept  to  an  absolute  minimum,  or  evolution  will  be  hindered  by  expensive  and  lengthy 
integration  and  testing.  One  way  to  do  this  is  to  require  that  systems  must  partition 
common  functions  in  a  common  way”  (Committee  on  the  FORCEnet  Implementation 
Strategy,  2005).  Due  to  the  inherent  complexity  and  amount  of  systems  within  the  Fleet, 
using  an  OA  approach  could  eventually  lead  to  problems  with  interface  maintenance.  As 
OA  takes  hold  and  becomes  the  standard  for  architectural  design,  the  amount  of 
interfaces  will  grow  and  expand  to  a  point  that  could  become  unmanageable.  Care  must 
be  taken  to  ensure  this  does  not  occur.  As  pointed  out,  the  partitioning  of  functions  in  a 
common  way  is  a  mitigation  technique,  but  this  requires  due  diligence  throughout  the 
Navy,  and  very  detailed  requirements  development  to  ensure  that  component 
functionality  is  partitioned  in  a  manner  that  will  facilitate  reuse  across  multiple  platforms. 
While  this  poses  a  technical  and  managerial  limitation  to  OA,  there  are  other  factors  that 
may  contribute  to  the  inability  of  an  organization  to  transition  to  an  OA  framework. 

While  not  an  inherent  technical  limitation  to  open  architecture,  implementation  of 

an  OA  framework  can  be  troublesome.  Transitioning  legacy  systems  to  ones  that  use  an 
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open  architecture  framework  has  the  potential  for  huge  up-front  costs  and  reoccurring 
maintenance  costs.  In  order  to  make  the  transition,  new  strategies  in  both  training  and 
technology  must  be  developed  so  that  expertise  in  the  new  architecture  can  be  achieved. 
Investments  in  infrastructure  upgrades  to  support  the  OA  and  a  reevaluation  of 
application  software  will  be  required,  necessitating  more  costs  in  the  near  term. 
Middleware,  software  that  acts  as  an  interface  between  proprietary,  legacy  systems  and 
OA  systems,  must  be  used  in  the  transition,  causing  additional  funding  requirements. 
The  need  to  support  both  the  current  proprietary  systems  and  the  new  OA  systems  can 
become  costly  in  both  operational  and  maintenance  environments.  A  transition  period 
could  last  as  long  as  10  years,  during  which  time  both  architectures  must  be  supported 
and  maintained  in  order  to  preserve  operational  capabilities.  As  the  proprietary  systems 
become  obsolete,  they  will  require  specialized  support  until  they  reach  the  end  of  their 
lifecycle  and  are  replaced. 

C.  DEPARTMENT  OF  THE  NAVY  OA  TRANSITION 

Realizing  that  the  proprietary,  legacy  systems  that  comprise  the  majority  of  the 
systems  within  the  Department  of  the  Navy  are  limited  in  their  processing  power; 
difficult  to  upgrade  and  expand  capabilities;  and  are  not  on  the  same  technological  level 
as  their  commercial  counterparts,  the  DON  has  determined  that  an  OA  engineering 
framework  is  needed  in  its  approach  to  systems  development.  To  achieve  this  transition, 
the  PEO  IWS,  OA  Division  was  created  as  the  responsible  organization.  From  this 
organization  came  the  Open  Architecture  Computing  Environment  (OACE)  which  is  the 
“overall  set  of  resources  used  in  OA  systems”  (OACE  Design  Guide  1.0,  2004).  The 
PEO  IWS,  OA  has  set  about  to  implement  the  OACE  and  has  provided  a  roadmap  to 
realize  this  goal. 

1.  OACE  Compliance  Categories 

The  foundation  for  the  OA  migration  strategy  begins  with  determining 
compliance  categories  that  will  be  used  to  identify  approaches  for  systems  to  operate 
within  an  OA  environment.  Figure  2  outlines  these  categories. 
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Figure  2.  OACE  Compliance  Categories  (OACE  Tech  and  Stds  1.0,  2004) 


Category  1  provides  for  hardware  adapters  for  non-OACE  compatible  legacy 
systems.  This  is  the  lowest  level  approach  and  would  be  well  suited  for  applications  that 
are  near  their  end  of  life  and  will  not  be  maintained,  or  will  not  be  transitioned  into  an 
OA  framework  due  to  operational  requirements.  Category  2  goes  a  step  further  and 
implements  the  concept  of  middleware.  Legacy  applications  are  isolated  from  OACE 
compliant  systems  through  the  application  of  OACE  compliant  middleware.  This  is  the 
fist  category  were  OACE  compliance  is  addressed.  Category  3  is  one  of  two  fully 
compliant  categories  (the  other  being  Category  4)  where  OACE  standards  and  interfaces 
are  completely  adhered  to.  Lastly,  Category  4  provides  all  the  attributes  of  Category  3, 
but  it  also  ensures  that  common  functions  and  services  are  applied.  The  concept  of 
common  functions  and  services  facilitates  reuse  of  the  software  across  multiple  platforms 
and  systems,  as  software  components  are  derived  through  functional  divisions. 
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With  a  basic  understanding  of  “where  we  are”  a  strategy  to  get  to  “where  we  want 
to  be”  can  be  generated. 

2,  Strategy 

Operational  responsibilities  necessitate  a  phased  approach  to  implementing  an  OA 
framework  within  the  DON.  Figure  3  outlines  the  phased  approach  to  implementing  OA 
with  respect  to  the  compliance  categories. 
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Figure  3.  DON  OA  Strategy  (slide  presentation  by  Mike  Rice,  Deputy  PM,  OA  and  Mike 

Russell,  Anteon  Corp.  for  E-Gov  Conference,  2004) 


The  transition  from  each  level  can  be  correlated  to  a  phase  within  the  OA 
Transformation  Roadmap,  presented  in  Figure  4.  Each  movement  upwards  in  the  level  of 
compliance  is  directly  tied  to  a  schedule  and  phased  transition  so  that  operational 
capabilities  are  not  affected.  With  each  step  the  Navy  gets  closer  to  the  ultimate  goal  of 
producing  systems  that  “will  be  fully  interoperable  with  all  the  systems  which  they  must 
interface,  without  major  modifications  of  existing  components”  (Rice  and  Russell,  2004). 
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OA  Transformation  Roadmap 


PY  ^  Q  Fleet-wide  Introduction  of 
and  Beyond  Category  4/5  Compliant  Combat 
Systems 


FY 05 - 10  Develop  Category  4/5 
Software  Applications 


FY  04  -  08  Equip  LCS,  Aegis,  CVs,  and  Amphibs  with 

Category  3  Capability 


Define  and  Pursue  Technical  and 
Functional  Architecture 


Figure  4.  DON  OA  Transformation  Roadmap  (slide  presentation  by  Mike  Rice,  Deputy 
PM,  OA  and  Mike  Russell,  Anteon  Corp.  for  E-Gov  Conference,  2004) 
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III.  THE  KNOWLEDGE  VALUE  ADDED  METHODOLOGY 


A.  MEASURING  VALUE  WITHIN  THE  DEPARTMENT  OF  THE  NAVY 

(DON) 

One  of  the  greatest  hurdles  that  face  the  Department  of  Defense  is  measuring  the 
value  associated  with  its  information  technology  systems  and  the  processes  that  function 
within,  and  in  conjunction  with,  these  systems.  Webster’s  dictionary  provides  the 
definition  of  value  as,  “the  monetary  or  relative  worth,  utility  or  importance  of 
something,”  and  seems  to  fit  within  the  context  of  those  systems  that  function  in  non¬ 
revenue  generating  environments  such  as  the  DON.  In  the  commercial  world,  value  can 
be  measured  through  the  revenue  generated  by  an  information  technology  system,  or  by 
the  cost  savings  that  the  system  may  achieve.  However,  within  the  Federal  Government 
(specifically  the  Department  of  the  Navy)  and,  for  that  matter,  any  non-revenue 
generating  entity,  monetary  revenue  is  not  always  an  easily  interpreted  measurement  of 
value. 

With  the  introduction  of  the  Information  Technology  Management  Reform  Act 
(ITMRA),  better  known  as  the  Clinger-Cohen  Act  of  1996,  the  Federal  Government  was 
mandated  to  provide  a  measurement  of  performance  of  their  information  technology 
systems,  and  that  measure  would  be  determined  by  “how  well  the  information  technology 
supports  the  programs  of  the  executive  agency”  (ITMRA).  This  was  taken  further  by 
then  Secretary  of  Defense  Cohen  to  define  a  means  of  evaluation  that  will  “utilize 
mission  outcome  based  performance  measurements  as  the  cornerstone  for  information 
technology  performance  assessments”  (Appendix  K,  Annual  Defense  Report,  1999).  The 
foundation  having  been  laid,  the  performance  metrics,  or  measurements  indicators  are  left 
to  the  discretion  of  the  program  manager. 

Office  of  Management  and  Budget  (0MB)  Circular  A- 11  requires  that  an  Exhibit 
300  I.C.  be  submitted  to  0MB  for  any  major  IT  initiative  acquired  after  2005.  Table  3  is 
an  example  of  a  possible  Exhibit  300  I.C.  (example  does  not  include  “Baseline”, 
“Planned  Improvements  to  the  Baseline”  and  “Actual  Results”  as  it  is  only  designed  to 
illustrate  possible  measurements).  The  four  “Measurement  Area”  entries  are  mandatory, 
while  the  “Measurement  Category”  and  “Measurement  Indicator”  are  left  to  the 
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discretion  of  the  program  manager  or  agency.  Indicators  must  be  tailored  to  eaeh  speeific 
system  and  must  provide  clearly  defined  and  measurable  outputs  that  are  attributable  to 
the  “Measurement  Category”  and  “Measurement  Area”.  Quantitative  versus  qualitative 
indicators  are  the  preferred  measure  so  that  a  determination  can  be  made  as  to  how  the  IT 
initiative  will  support  the  strategic  goals  and  objectives  of  the  organization. 


Fiscal 

Year 

Measurement 

Area 

Measurement 

Category 

Measurement 

Indicator 

Baseline 

Ranned 
Improvements 
to  the  Baseline 

Actual 

Results 

2005 

Mission  and 
Business 

Results 

Planning  and 

Resource 

Allocation 

Degree  to  which 
agency  migrates  to  its 
IT  Enterprise 
Architecture 

2005 

Customer 

Results 

Timeliness  & 
Responsive¬ 
ness 

%  ofEnterprise 
Architecture 
requirements, 
guidance,  and 
deliverables  provided 
to  agency  EA  staff  on 
schedule 

2005 

Processes  and 
Activities 

Financial 

Cost  avoidance 
attributable  to 
consolidations 
identified  in  Target 

EA 

2005 

Technology 

Effectiveness 

%  of  internal  users 
who  report  using  the 
EA  management 
system  as  intended 

Table  3.  Example  Exhibit  300  I.C.  (Performance  Reference  Model,  Vol.  II,  2003) 


Historically,  metrics  have  been  assoeiated  with  financial  returns  on  investment, 
but  as  shown  in  table  3,  the  measurement  indieators  for  a  government  IT  system  need  to 
be  tied  to  mission  outcome,  not  the  overall  input  to  the  system. 

The  Knowledge  Value  Added  (KVA)  methodology  applies  the  idea  that  the 
inherent  knowledge  in  a  process  is  a  viable  determinant  of  the  process’  value.  Through 
the  application  of  the  KVA  methodology,  knowledge  within  eore  proeesses  of  an 
organization  ean  be  measured  and  the  resulting  return  on  knowledge  ean  be  used  to 
provide  a  means  of  evaluating  multiple  proeesses  through  common  units  of  measurement. 
This  methodology  does  not  require  that  the  common  units  be  reflected  in  the  form  of 
monetary  or  finaneial  value.  The  proeesses  within  the  operational  context  of  a  CIC  can, 
through  KVA,  all  be  described  in  eommon  units  of  output,  the  resulting  productivity  ratio 
(ROK)  can  then  be  evaluated  to  determine  where  effieieneies  may  be  obtained. 
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B,  THE  KVA  SOLUTION 

1,  Knowledge  Value-Added  (KVA)  Theory 

Developed  by  Dr.  Thomas  Housel  (Naval  Postgraduate  School)  and  Dr.  Valery 
Kanevsky  (Agilent  Labs)  over  15  years  ago,  KVA  is  a  means  to  value  the  knowledge 
assets  within  an  organization.  Built  upon  complexity  (measure  of  common  unit  of 
change)  theory,  the  methodology  asserts  that  core  processes  within  an  organization 
process  inputs  and  add  value  to  those  inputs,  changing  the  inputs  into  outputs  through 
some  application  of  change,  thereby  producing  an  output  that  has  exhibited  a 
transformation  from  the  original  input.  The  theory  states  that  the  difference  (i.e.,  change) 
between  the  inputs  from  that  of  the  outputs  is  the  value  provided  by  the  organization’s 
assets  (i.e.,  people,  processes  or  IT  systems)  which  acted  upon  the  inputs.  In  this  manner, 
we  can  see  that  the  knowledge  within  a  process  is  proportional  to  the  amount  of  change 
made  to  an  input  to  produce  the  output.  This  knowledge  value,  measured  in  standard 
units  of  output,  facilitates  the  analysis  of  multiple,  differing  processes  throughout  an 
organization,  and  empowers  management  to  make  more  informed  decisions  concerning 
their  core  processes. 

Knowledge  embedded  in  core  processes  of  an  organization  can  now  be  evaluated 
and  compared  across  the  entire  organization.  KVA  produces  a  common  unit  of 
knowledge  that  serves  as  a  surrogate  for  units  of  output  in  a  standard  way  (Housel  and 
Bell,  2001),  and  in  doing  so,  provides  a  decision  support  mechanism  for  those  within  the 
organization  to  make  more  informed  decisions  concerning  the  insertion  of  information 
technology  into  the  processes.  With  a  better  understanding  of  where  knowledge  assets 
reside,  a  more  in  depth  evaluation  of  an  organization’s  processes  can  be  achieved  where 
efficiencies  can  be  expanded  upon  and  deficiencies  can  be  rooted  out  and  changed. 

2,  KVA  Assumptions 

With  any  methodology  or  framework  there  are  certain  assumptions  that  must  be 
addressed  so  that  a  basic  understanding  can  be  agreed  upon  and  the  level  of  uncertainty 
can  be  mitigated.  With  KVA,  the  following  assumptions  apply: 

1 .  There  must  be  an  input,  a  process  that  acts  upon  the  input  to  produce  an 
output. 
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2.  The  type  of  proeess  (i.e.,  IT  system,  employees,  proeedures  etc.)  which 
acts  upon  the  input  is  irrelevant  to  the  measure  of  change. 

3.  Should  the  input  equal  the  output,  then  there  was  no  change,  nor  any  value 
added  from  the  process. 

4.  Value  created  by  the  process  is  relative  to  the  change  that  the  process 
applies  to  the  input. 

5.  Change  is  measured  by  the  amount  of  knowledge  required  to  produce  the 
change. 

6.  Accepting  4  and  5  above,  value  and  knowledge  are  then  related 

7.  Knowledge  can  be  defined  as  the  amount  of  time  it  takes  an  average 
learner  to  acquire  the  knowledge. 

These  assumptions  are  visually  represented  in  Figure  5,  below. 

Fundamental  Assumptions  of  KVA 

Underlying  Model:  Change,  Knowledge  and  Value  are  Proportionate 

Input  Process  Output 

X - ►(  P  ) - -Y 

P(X)  =  Y 

Fundamental  Assumptions: 

1.  If  X=Y,  no  value  has  been  added. 

2.  “Value”  is  proportional  to  change. 

3.  “Change"  can  be  measured  by  the  amount  of 
knowledge  required  to  make  the  change. 

So  “value”  is  proportional  to  “change”  is 

proportional  to  “amount  of  knowledge  required 
to  make  the  change. 

Figure  5.  Assumptions  of  KVA  (Housel  and  Bell,  2001) 
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3,  KVA  Approaches 

The  KVA  methodology  presents  a  very  robust  and  dynamic  framework  that  can 
use  three  different  approaches  for  capturing  the  knowledge  inherent  in  the  core  processes 
within  an  organization.  While  these  approaches  vary  in  application,  neither  is  better  or 
worse  than  the  other,  they  simply  present  different  collection  means  for  deriving  a  result. 
It  is  important  to  note  that  once  an  approach  is  decided  upon,  it  should  be  applied 
consistently  throughout  the  organization.  Processes  cannot  be  correctly  evaluated  if  they 
use  differing  approaches  to  determine  their  value.  While  the  learning  time  approach  is 
applicable  to  this  thesis,  each  of  the  three  methods  is  described  in  Table  4. 
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Steps 

Learning  Time 

Process  Description 

Binary  Query  Method 

1 

Identin-  core  process  and  its  sub  processes. 

Establish  common 
units  andles'el  of 
complexity'  to 
measure  learning 
tune. 

Describe  die  products  in 
terms  of  die  instructions 
required  to  reproduce 
them  and  select  unit  of 
process  description. 

Create  a  set  of  binary 
yes  or  no  questions 
such  diat  all  possible 
outputs  are  represented 
as  a  sequence  of  yes  or 
no  answers. 

3 

Calculate  learning 
time  to  execute  each 
sub  process. 

Calculate  number  of 
process  descnpdon 
words,  pages  in  manual, 
and  lines  of  computer 
code  pertaining  to  each 
sub  process. 

Calculate  length  of 
sequence  of  yes  or  no 
answers  for  each  sub 
process. 

4 

Designate  sampling  time  period  long  enough  to  c^ture  a  representative  sample 
of  the  core  processes  final  product  or  serstce  ou^ut. 

5 

Multiply  the  learning 
tune  for  each  sub 
process  by  the  number 
of  times  the  sub 
process  executes 
during  die  sample 
period. 

Multiply  the  number  of 
process  words  used  to 
describe  each  sub  process 
by  the  number  of  times 
the  sub  process  executes 
during  sample  period. 

Multiply  the  length  of 
die  yes  or  no  string  for 
each  sub  process  by  die 
number  of  times  the 
sub  process  executes 
during  sample  period. 

6 

Calculate  cost  to  execute  knowledge  (learning  time  and  process  instructions)  to 
determine  process  costs. 

7 

Calculate  ROK  and  ROP  and  interpret  die  results. 

Table  4.  Three  Approaches  to  KVA  (Housel  and  Bell,  2001) 
a.  Learning  Time 

This  approach  uses  a  measurement  based  on  the  time  it  would  take  an 

average  person  to  learn  the  process  in  question.  The  measurements  must  be  in  common 

units  of  time  (i.e.,  hours,  days,  weeks  etc.)  and  should  be  verifiably  reliable.  To  obtain  the 

learning  time  measurements,  all  time  required  to  learn  the  process  must  be  indicated. 

This  may  include  training  at  a  formal  school,  on-the-job-training  (OJT),  distance 

education  and  any  other  source  of  training  that  would  be  relevant  to  the  generation  of  an 

output  by  means  of  the  process  indicated.  Generally  SME’s,  training  manuals  and 
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standard  operating  procedures  can  provide  a  means  for  determining  the  actual  learning 
time,  although  this  type  of  information  gathering  can  be  prone  to  subjectivity.  To  avoid 
this  and  mitigate  the  risk  of  obtaining  erroneous  data,  a  correlation  among  two  estimates 
can  be  calculated  to  ensure  the  most  reliable  and  accurate  data  has  been  provided. 

Correlation  can  be  achieved  by  obtaining  an  ordinal  ranking  based  on  the 
difficulty  to  learn  each  sub  process  within  the  organization.  SME’s  are  asked  to  rank 
order  each  sub  process  in  order  of  difficulty  to  learn.  This  ranking  is  then  correlated 
against  the  actual  learning  time  data  that  was  provided.  Should  the  two  provide  a 
correlation  of  80%  or  greater,  the  data  can  be  considered  to  be  reliable.  A  correlation 
below  80%  assumes  a  discrepancy  in  either  the  rank  order  or  the  actual  amount  of 
learning  time  required  for  each  process.  This  can  occur  when  SME’s  do  not  completely 
understand  the  problem  domain  and  provide  learning  time  estimates  that  are  faulty. 
Restructuring  the  learning  time  question  or  requesting  a  revalidation  will  normally  be 
required. 

b.  Process  Description 

This  approach  measures  the  number  of  instructions  needed  to  reproduce 
the  outputs  produced.  Using  the  process  description  approach  enables  the  KVA 
methodology  to  achieve  a  higher  level  of  detail  in  the  process  description  than  does  the 
learning  time  approach.  It  requires  a  more  detailed  and  analytical  description  of  each 
process  and  the  amount  of  instructions  needed  to  produce  each  output.  The  process 
instructions  are  calibrated  in  terms  of  their  complexity. 

c.  Binary  Query 

Utilizing  the  binary  query  approach  requires  the  creation  of  a  set  of  binary 
yes/no  questions  such  that  all  possible  outputs  are  represented  as  sequences  of  yes/no 
answers  (i.e.,  bits).  These  sequences  can  then  be  calculated  and  value  can  be  attributed  to 
the  outcome. 

C.  RETURN  ON  KNOWLEDGE  (ROK) 

Return  on  Knowledge  (ROK)  is  the  ratio  of  revenue  allocated  to  each  core  area 
compared  to  its  corresponding  expenses  (Housel  and  Bell,  2001).  The  essence  of  KVA  is 
found  in  the  ROK  ratio  that  the  methodology  provides.  As  stated  earlier,  knowledge  is  a 
surrogate  for  common  unit  outputs,  so  ROK  provides  a  means  for  determining  a 
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knowledge  value  to  cost  ratio  for  all  processes  within  an  organization.  Proper  application 
and  analysis  of  ROK  can  provide  an  organization  with  a  better  understanding  of  the 
productivity  of  its  knowledge  assets,  where  they  are  located  and  how  efficiently  they  are 
being  applied  throughout  the  organization.  For  non-revenue  generating  organizations  this 
can  be  a  force  multiplier  for  validating  processes  and  IT  systems. 
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IV.  PROOF  OF  CONCEPT 


A.  INTRODUCTION 

Program  Executive  Office,  Integrated  Warfare  Systems  (PEO  IWS),  Open 
Architecture  Division  is  charged  with  implementing  the  Navy’s  OA  plans,  policies  and 
initiatives.  One  of  these  initiatives  is  the  implementation  of  an  open  architecture 
approach  to  developing  a  situational  awareness  (SA)  system  for  the  DD(X)  project.  To 
accomplish  this,  PEO  IWS  has  looked  at  both  the  AEGIS  and  SSDS  platforms  to 
determine  specific  elements  of  each  track  management  system  that  could  possibly  be 
reengineered  using  open  architecture  approach  for  placement  into  the  new  DD(X) 
program.  In  doing  this,  metrics  must  be  looked  at  to  determine  the  best  modules  that 
could  be  candidates  for  open  architecture. 

This  proof  of  concept  will  take  information  from  subject  matter  experts  from  both 
the  Surface  Warfare  Elect  and  from  training  commands  at  Dahlgren  (AEGIS)  and 
Wallops  Island  (SSDS).  The  process  information  garnered  from  these  SME’s  will  then 
be  aggregated  to  provide  an  average  for  each  process  (multiple  sources  provide  multiple 
figures,  so  an  average  will  be  calculated  to  ensure  a  more  accurate  result  is  achieved) 
using  the  KVA  methodology.  This  analysis  is  the  “As  Is”  baseline.  The  resulting  ROK’s 
will  then  by  analyzed  to  determine  if  information  technology,  specifically  with  relation  to 
systems  built  using  an  open  architecture  approach,  could  be  inserted  to  enhance  the 
operational  capabilities  of  a  Combat  Information  Center  (CIC)  aboard  a  naval  vessel. 
Easily,  a  Real  Options  analysis  can  be  conducted  on  possible  ROK  values  generated  from 
the  “To  Be”  model  of  the  SA  system,  thereby  providing  PEO  IWS  with  an  idea  of 
specific  processes  within  the  SA  system  that  could  be  reengineered  with  an  open 
architecture  approach  to  provide  the  greatest  value  to  the  operational  fleet. 

B.  HYPOTHESIS 

Measures  of  effectiveness  (MOE)  for  open  architecture  in  an  operational 
environment  can  be  derived  through  the  application  of  the  Knowledge  Value  Added 
Methodology.  These  MOE  metrics  can  then  be  used  to  support  decisions  for  acquisition, 
procurement,  development  and  integration  of  software  components  by  generating  a  return 
on  knowledge  for  each  core  process  within  the  situational  awareness  arena. 
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C.  ANALYSIS  AND  DATA  COLLECTION 

1,  Track  Management  in  the  Combat  Information  Center  (CIC) 

Each  platform  (AEGIS  and  SSDS),  and  for  that  matter,  each  ship,  has  different 
procedures  and  policies  regarding  the  situational  awareness  or  track  management 
functions  within  the  CIC.  While  these  functions  may  vary,  the  cores  of  the  processes  that 
make  up  the  system  are  basically  the  same  and  have  been  validated  by  both  Elect 
personnel  and  personnel  at  the  formal  schools.  The  current  track  management  process 
has  a  mixture  of  automation  and  manual  processes  involved,  and  while  there  are 
variances  as  to  the  amount  of  each,  an  aggregated  amount  will  be  used  so  that  an  average 
output  can  be  assumed  for  estimation  purposes. 

Track  management  within  a  CIC  is  a  complex  process,  involving  multiple  sub 
processes  and  multiple  individuals.  Outputs  from  one  sub  process  may,  or  may  not,  have 
a  bearing  on  another  sub  process  within  the  overall  situational  awareness  process.  This 
ability  of  each  sub  process  to  possibly  be  a  stand-alone  process  or  be  integrated  into  the 
bigger  SA  system  provides  for  a  robust  and  highly  capable  system,  but  also  makes  an 
analysis  of  the  system  very  complicated  and  challenging. 

2.  Data  Collection  Challenge 

Due  to  the  complex  nature  of  the  track  management  system  in  the  CIC,  collecting 
appropriate  data  that  can  be  analyzed  through  the  KVA  methodology  was  challenging. 
Outputs,  learning  time  and  touch  time  of  many  sub  processes  that  make  up  the  entire 
system  are  not  generally  collected  or  retained.  Within  the  Navy,  training  times  and 
required  on-the-job-training  (OJT)  are  targeted  at  specific  watch  stations  rather  than 
specific  processes,  which  is  what  KVA  requires.  Due  to  this,  data  derived  for  the  purpose 
of  this  analysis  was  extracted  through  conversations  with  SME’s  and  reviewing  of 
Personal  Qualification  Standards  (PQS).  Multiple  SME’s  were  contacted  so  that  an 
aggregated  sample  could  be  achieved. 

D,  DEFINING  THE  TRACK  MANAGEMNT  PROCESS 

1.  CIC  Overview 

With  respect  to  this  thesis,  the  following  watch  stations  were  identified  as  having 
a  direct  impact  on  the  track  management  process  within  a  CIC.  These  watch  stations, 
while  sometimes  being  associated  with  different  names,  were  consistent  on  both  AEGIS 
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and  SSDS  platforms.  Additionally,  though  the  watch  stations  have  specific  tasks  and 
responsibilities,  in  an  actual  CIC  all  personnel  listed  can  be  actively  involved  in  any,  or 
all,  aspects  of  track  management  (correlation,  identification,  tracking,  and  relaying). 
While  there  will  be  variances  from  ship  to  ship;  Figure  6  is  a  generalized  organizational 
chart  of  the  personnel  within  a  CIC  that  are  actively  involved  with  track  management. 


CIC  ORGANIZATIONAL  CHART 


Figure  6.  CIC  Organizational  Chart 

2,  CIC  Watch  Standee  Descriptions 

a.  Tactical  Action  Officer  (TAO) 

The  Tactical  Action  Officer  has  overall  responsibility  for  actions  within 
the  CIC.  The  TAO  leads  the  CIC  watch  team  and  coordinates  the  track  management 
functions  within  the  CIC.  As  the  senior  watch  station  within  the  CIC,  the  TAO  is 
responsible  for  most  track  management  decisions  made  within  the  CIC.  The  TAO  watch 
station  is  predominantly  filled  by  a  field  grade  officer.  Additional  duties  that  may  be 
accomplished  by  the  TAO  outside  of  the  track  management  domain  are  not  applicable  to 
this  thesis. 
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b.  Anti-Air  Warfare  Coordinator  (AA  WC) 

The  Anti-Air  Warfare  Coordinator  is  responsible  for  the  overall  air  pieture 
within  the  CIC.  A  majority  of  the  time,  the  AAWC  will  be  the  seeond  senior  offieer  in 
the  CIC.  The  AAWC  directs  a  team  of  operators  in  the  detection,  identification  and 
dissemination  of  aircraft  tracks  within  the  ship’s  airspace.  The  AAWC  will  control 
movement  of  friendly  aircraft  assigned  to  the  ship,  attend  intelligence  briefings  and 
maintain  a  general  awareness  of  the  air  picture  during  all  phases  of  CIC  operations. 
While  charged  with  the  overall  status  of  the  air  picture,  the  AAWC  will  delegate  many  of 
the  specific  track  management  tasks  to  subordinates  so  as  to  keep  track  of  the  overall  air 
picture.  The  AAWC  watch  station  is  predominantly  filled  by  a  junior  officer.  Additional 
duties  that  may  be  accomplished  by  the  AAWC  outside  of  the  track  management  domain 
are  not  applicable  to  this  thesis. 

c.  Surface  Warfare  Coordinator  (SUWC) 

The  Surface  Warfare  Coordinator  is  responsible  for  the  overall  surface 
picture  within  the  CIC.  The  SUWC  directs  a  team  of  operators  in  the  detection, 
identification  and  dissemination  of  surface  tracks  within  the  ship’s  airspace.  The  SUWC 
will  attend  intelligence  briefings  and  maintain  a  general  awareness  of  the  surface  picture 
during  all  phases  of  CIC  operations.  While  charged  with  the  overall  status  of  the  surface 
picture,  the  SUWC  will  delegate  many  of  the  specific  track  management  tasks  to 
subordinates  so  as  to  keep  track  of  the  overall  surface  picture.  The  SUWC  watch  station 
is  predominantly  filled  by  a  junior  officer.  The  Additional  duties  that  may  be 
accomplished  by  the  SUWC  outside  of  the  track  management  domain  are  not  applicable 
to  this  thesis. 

d.  Combat  Systems  Coordinator  (CSC) 

Usually  the  senior  ranking  enlisted  in  the  CIC,  the  Combat  Systems 
Coordinator  is  charged  with  monitoring  and  initiating  troubleshooting  procedures  for 
communications  systems.  Tactical  Digital  Information  Link  (TADIL)  Links  and  the 
Identify  Friend  or  Foe  (IFF)  system.  The  CSC  is  directly  responsible  for  identification 
processes  within  the  CIC,  to  include  AEGIS  ID  doctrine  and  track  management  operator 
performance.  The  CSC  provides  support  to  all  operators  within  the  CIC  in  the 
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management  of  air  and  surfaee  tracking,  identifying  and  relaying.  Additional  duties  that 
may  be  accomplished  by  the  CSC  outside  of  the  track  management  domain  are  not 
applicable  to  this  thesis. 

e.  Tactical  Information  Coordinator  (TIC) 

The  Tactical  Information  Coordinator  operates  and  maintains  the  TADIL 
A  (Link  11)  and  TADIL  J  (Link  16)  between  friendly  air  and  surface  craft  within  the  area 
of  operations.  The  inherent  importance  of  the  Link  picture,  the  TIC  is  primarily  focused 
on  ensuring  a  clear,  coherent  picture  is  presented  over  the  Links.  The  TIC  is  responsible 
for  identifying  and  quickly  resolving  any  correlation  issues  (“same  contact,  multiple 
tracks”).  The  TIC  watch  station  is  predominantly  filled  by  a  junior  enlisted.  Additional 
duties  that  may  be  accomplished  by  the  TIC  outside  of  the  track  management  domain  are 
not  applicable  to  this  thesis. 

f  Identification  Supervisor  (IDS) 

The  Identification  Supervisor  is  charged  with  the  overall  identification 
process  within  the  CIC.  The  IDS  will  be  responsible  for  IFF  challenges,  query  and/or 
warning  procedures  directed  at  suspect  contacts  and  inputting  of  information  into  the  CIC 
track  database  (AEGIS  Command  and  Display  system).  The  IDS  will  monitor  all  tracks 
and  ensure  timely  and  accurate  identification  can  be  generated  so  that  decisions  can  be 
made  as  to  the  intent  of  the  contact.  The  IDS  is  primarily  focused  on  the  air  picture  (due 
to  the  immanent  danger  of  air  contacts  with  relation  to  surface  contacts),  but  does  support 
the  surface  picture  as  well.  The  IDS  watch  station  is  predominantly  filled  by  a  junior 
enlisted.  Additional  duties  that  may  be  accomplished  by  the  IDS  outside  of  the  track 
management  domain  are  not  applicable  to  this  thesis. 

3,  Defined  Track  Management  Sub  Processes 

The  process  of  track  management  within  a  CIC  is  a  very  complex  and 
sophisticated  process  involving  multiple  watch  stations  and  technological  systems.  In 
order  to  analyze  the  process  with  the  KVA  methodology  it  was  necessary  to  decompose 
the  track  management  process  into  individual  sub  processes.  This  decomposition  enables 
a  more  diverse  analysis  of  each  functional  area  within  the  track  management  process. 
The  core  processes  that  make  up  track  management  are  provided  below  in  Figure  7. 
These  core  sub  processes  were  derived  from  correspondence  with  multiple  Subject 
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Matter  Experts  in  both  the  AEGIS  and  SSDS  communities.  While  each  of  the  sub 
processes  may  differ  from  ship  to  ship,  the  SME’s  concluded  that  these  4  sub  processes 
reflected  the  procedures  that  are  conducted  within  a  CIC  for  track  management.  These 
sub  processes  were  further  decomposed  in  order  to  evaluate  the  specific  functions 
associated  with  each.  Again,  SME’s  were  consulted  and  the  basic  understanding  was  that 
the  17  functional  areas  were  at  a  sufficient  level  of  decomposition  for  this  thesis.  While 
the  SME’s  said  there  is  no  definitive  sequential  order  in  which  the  steps  take  place,  the 
figure  provides  a  possible  sequence  that  could  occur  so  as  to  provide  a  visual 
representation  for  the  reader. 


TRACK  MANAGEMENT  SUBPROCESSES 


Correlate:  - ►  Track:  - ►  Identify: - ►  Relay: 


Obtain  Link  Information 

Monitor  Suspect  Tracks 

ID  "same  contact, 
multiple  track" 

Update  Tracks 

Verify  other  track 
sources 

Verify  Sources  for  track 

Verify  IFF  Signal 


Verify  EW  Signal 


Verify  Point  of  Origin 


Match  Against  ATO 


Match  Against  CommAir 
Profile 


Match  Against  Intel  Info 


Examine  Kinematic  Data 


Obtain  Visual  ID 


Conduct  Verbal  Query 


Send  Over  Links 


Discuss  Picture  with 
Battle  Force  Units 


Eigure  7.  Track  Management  Sub  Processes 


Each  of  these  sub  processes  and  associated  functions  are  conducted  throughout 
the  track  management  process.  While  some  of  the  sub  processes  are  not  always 
conducted,  the  listing  provides  an  aggregated  decomposition  that  can  be  generalized  for 
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both  the  AEGIS  and  SSDS  platforms,  and  each  associated  ship  within  those  platforms. 
Each  sub  process  is  further  defined  below  so  that  each  can  be  understood  in  the  context  of 
this  thesis. 

a.  Correlate 

Eor  the  purpose  of  this  thesis,  correlate  will  be  defined  as  the  ability  to 
combine  target  detections  from  individual  radars,  identification  friend  or  foe  (lEE)  system 
and  any  additional  electronic  support  measures  systems  that  may  be  available  to  obtain  a 
single,  composite  track  that  can  be  used  to  enhance  the  common  operational  picture 
within  the  CIC.  This  sub  process  is  further  broken  into  more  specific  functions  below. 

1.  OBTAIN  EINK  INEORMATION:  Tactical  Digital 

Information  Eink  (TADIE)  Einks  A  and  J  are  the  primary  means  by  which  elements 
within  a  battle  group  can  exchange  information  about  their  individual  air  and  surface 
pictures.  The  data  passed  provides  each  element  with  an  updated  common  operational 
picture  so  as  to  maintain  a  real-time  situational  awareness  of  the  battle  force  area  of 
operations.  TADIE  A,  commonly  referred  to  as  Eink  11,  is  the  older  of  the  two,  and  is 
found  on  all  platforms.  TADIE  A  requires  a  Net  Control  Station  (NCS)  to  manage  the 
network  and  facilitate  controlled  communications  where  elements  will  transmit  data  to 
the  NCS,  and  only  once  all  elements  have  relayed  their  data  will  the  NCS  provide  a 
consolidated  picture  to  the  entire  battle  force.  TADIE  J,  commonly  referred  to  as  Eink 
16,  is  the  newer  system  and  provides  for  higher  data  transfer  rates,  resistance  to  jamming 
and  the  ability  for  multiple  elements  to  transmit  data  simultaneously,  without  the  use  of  a 
NCS.  Some  elements  within  the  Elect  still  do  not  possess  the  Eink  16  capability.  The 
process  of  obtaining,  understanding,  managing  and  utilizing  the  information  from  the 
Einks  is  the  crux  of  this  sub  process.  A  diagram  of  the  TADIE  J/Eink  16  architecture  is 
provided  in  Eigure  8  below.  The  process  is  highly  automated,  with  little  operator  input. 
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Figure  8.  Link  16  architecture 


2.  IDENTIFY  “SAME  CONTACT,  MUETIPEE  TRACKS”: 
Many  times  the  AEGIS  and  SSDS  platforms  will  identify  the  same  contact  with  multiple 
tracks  on  the  operator  consoles.  This  anomaly  must  be  corrected  so  that  the  operational 
picture  can  be  clearly  portrayed  to  the  battle  force.  The  process  of  identifying  when  there 
are  multiple  tracks  for  the  same  contact,  and  then  correcting  this  error  so  that  a  single 
track  is  promulgated  to  the  Elect.  This  is  currently  a  manual  process  that  requires  the 
operator  to  understand  the  anomaly  and  have  the  requisite  knowledge  to  identify  when  it 
is  occurring  and  the  ability  to  correct  the  duplication. 

3.  VERIFY  OTHER  SOURCES  FOR  TRACK:  Operators 
must  be  able  to  validate  any  and  all  sources  for  a  given  track.  This  will  sometimes 
require  verbal  communications  with  adjacent  elements  in  the  battle  force,  querying 
system  resources  and  understanding  the  multiple  sensor  nodes  that  are  available  at  any 
given  time  and  area  of  operations.  Should  a  track  come  from  a  non  organic  asset  of  the 
ship,  the  operator  must  be  able  to  contact  the  remote  source  and  confirm  the  information 
that  was  provided  for  the  given  track. 
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b.  Track 

Track  is  the  process  by  which  a  detected  track  is  monitored  and  managed. 
This  involves  both  operator  and  system  functions  and  procedures.  Visually  monitoring  a 
track  and  updating  its  status  into  multiple  systems,  as  required,  fall  into  the  purview  of 
this  process. 

1.  MONITOR  SUSPECT  TRACKS:  Once  a  track  has  been 
detected  it  has  the  ability  to  be  monitored.  Suspect  tracks  are  those  that  have  not  been 
identified  or  have  been  identified  as  “hostile”  or  “unknown”.  These  tracks  pose  a 
possible  threat  to  the  Fleet  and  must  be  monitored  until  they  are  identified  as  “friendly” 
or  have  been  determined  by  competent  authority  as  not  to  be  of  significant  threat  to  the 
Fleet.  This  is  still  a  highly  manual  process,  although  both  systems  can  be  programmed  to 
monitor  these  tracks  more  closely. 

2.  UPDATE  TRACK:  Once  a  track  has  been  detected  and  is 
in  the  process  of  being  monitored,  it  may  routinely  need  to  be  updated,  both  in  the  ship’s 
organic  systems  and  in  any  other  systems  that  may  require  track  integration.  An  update 
to  a  current  track  can  consist  of  any  myriad  of  information  that  is  applicable  to  the  track 
and  can  be  performed  at  any  time.  An  update  is  currently  a  manual  process  whereby  an 
operator  inputs  information  into  the  system  as  it  becomes  available.  While  updates  can 
be  performed  by  any  operator,  there  is  normally  one  individual  assigned  so  as  to  provide 
continuity  and  coordination  of  effort. 

3.  UPDATE  GLOBAL  COMMAND  AND  CONTROL 
SYSTEM  -  MARITIME  (GCCS-M):  The  Global  Command  and  Control  System 
enhances  the  operational  commander’s  war  fighting  capability  and  aids  in  the  decision¬ 
making  process  by  receiving,  retrieving,  and  displaying  information  relative  to  the 
current  tactical  situation.  GCCS-M  receives,  processes,  displays,  and  manages  data  on  the 
readiness  of  neutral,  friendly,  and  hostile  forces  in  order  to  execute  the  full  range  of  Navy 
missions  (e.g.,  strategic  deterrence,  sea  control,  power  projection,  etc.)  in  near-real-time 
via  external  communication  channels,  local  area  networks  (LANs)  and  direct  interfaces 
with  other  systems  (www.fas.org).  The  GCCS-M  is  updated  both  manually  and 
automatically.  The  system  uses  Link  1 1  for  connectivity,  but  has  the  ability  to  use  Link 
16  in  certain  instances.  Tracks  are  automatically  populated  in  GCCS-M  via  Link  11,  but 
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deletions  from  the  system  require  manual  intervention.  Due  to  the  fact  that  this  is  a 
planning  tool  which  provides  non-real  time  track  data,  there  is  little  emphasis  within  a 
CIC  to  update  and  monitor  GCCS-M.  A  problem  exists  when  staff  planners,  usually  at 
the  flag  officer  level,  rely  on  inaccurate  track  data  that  has  not  been  monitored,  and 
subsequently  updated,  by  operators  within  the  CIC. 

c.  Identification 

The  identification  sub  process  provides  the  greatest  decomposition  of  the 
track  management  process.  This  sub  process  involves  a  multitude  of  functions  that 
encompass  the  identification  of  detected  tracks.  The  processes  involved  in  identification 
are  both  manual  and  technology  driven,  and  are  the  crux  of  the  track  management 
process.  The  ability  to  correctly  identify  a  track  in  a  timely  and  efficient  manner  is,  quite 
possibly,  the  most  important  aspect  within  the  track  management  process,  which  is  why  it 
was  given  so  much  attention. 

1.  VERIFY  IDENTIFICATION  FRIEND  OR  FOE  (IFF) 
SIGNAF:  The  Identification  Friend  or  Foe  system  is  used  for  providing  quick  and 
accurate  recognition  of  friendly  aircraft  and  ships.  Each  friendly  military  aircraft/ship 
has  a  specific  IFF  code  associated  with  it.  Additionally,  certain  IFF  codes  are  used  by 
commercial  aircraft  internationally  to  provide  a  means  of  identification  in  support  of  the 
air  traffic  control  tower  missions.  The  unique  codes  and  their  functions  are  detailed 
below  in  Table  5. 
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IFF  MODE 

DESCRIPTION 

Mode  1 

Nonsecure.  low  cost  method  used  by  ships  to  track  aircraft  and  other  ships.  Military  application 
for  determination  of  type  of  aircraft  or  mission 

Mode  2 

Military  application  for  determination  of  aircraft  ID  number.  Additionally  used  by  aircraft  to  make 
carrier  controlled  approaches  to  ships  during  inclement  weather. 

Mode  3/A 

Standard  system  also  used  by  commercial  aircraft  to  relay  their  position  to  ground  controllers 
throughout  the  world  for  air  traffic  control  (ATC).  Commercially  known  as  Mode  A. 

Mode  4 

Secure  encrypted  IFF.  Military  uses  to  determine  whether  a  contact  is  a  friend  or  foe. 

Mode  C 

Provides  a  three  dimensional  altitude  response. 

Table  5.  Identification  Friend  or  Foe  Categories 

IFF  interrogation  is  almost  completely  automated.  The  system  interrogates  the  contact 
through  electronic  signals,  which  the  contact  will  provide  an  appropriate  response, 
depending  on  which  IFF  mode  it  is  utilizing.  Operators  only  need  to  monitor  this  process 
and  correct  any  anomaly’s  they  may  see. 

2.  VERIFY  ELECTRONIC  WARE  ARE  (EW)  EMISSIONS: 
Each  aircraft  type  gives  off  an  electronic  signature  that  is  specific  to  the  type  of  aircraft. 
This  signature  can  be  collected  and  interpreted  against  known  signatures.  This  process  is 
substantially  automated  in  the  collection  of  information,  but  due  to  its  processor 
requirements,  the  notification  is  not  automatic  as  it  would  crash  the  current  system.  The 
procedure  is  for  the  cryptographic  technician  to  verbally  send  a  report  to  the  CIC 
outlining  the  information  gained  from  the  emissions  of  the  aircraft. 

3.  VERITY  POINT  OF  ORIGIN:  Manual  in  nature,  this  is 
the  process  whereby  an  operator  will  try  to  determine  the  point  of  origin  of  a  contact. 
This  involves  knowledge  of  the  contacts  kinematics  information  and  verification  of 
additional  system  resources  (IFF,  EW,  Air  Tasking  Order  etc.). 
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4.  MATCH  AGAINST  AIR  TASKING  ORDER  (ATO):  The 
ATO  is  distributed  on  a  daily  basis  via  GCCS-M.  A  hard-copy  printout  will  be  provided 
to  CIC  personnel,  which  will  be  used  to  determine  if  a  contact,  based  on  time,  kinematics, 
IFF  and  EW  data  could  be  a  friendly  aircraft  depicted  in  the  daily  ATO.  This  is  a 
currently  a  completely  manual  process. 

5.  MATCH  AGAINST  COMMERCIAE  AIR  (CommAir) 
PROFIEE:  Commercial  air  traffic  use  specific  lanes  and  corridors  in  their  flight  patterns. 
These  lanes  and  corridors  are  circulated  and  well  known.  Additionally,  commercial 
aircraft  have  flight  profiles  (speed,  altitude,  emissions  etc.)  that  are  specific  to  the  civil 
and  commercial  industry.  The  process  of  matching  specific  kinematics,  IFF  and  EW 
information  to  that  of  known  commercial  profiles  can  be  done  almost  completely  through 
automation,  with  minimal  monitoring  for  questionable  contacts  that  may  not  trip  a 
CommAir  profile  doctrine. 

6.  MATCH  AGAINST  INTEFFIGENCE  INFORMATION; 
Intelligence  briefs  are  provided  on  a  daily  basis.  These  briefs  provide  the  most  current 
information  as  to  the  operational  situation,  friendly  and  enemy  forces  disposition  and  any 
additional  updates  as  may  be  relevant  to  the  Fleet.  At  a  minimum,  the  TAO,  AAWC  and 
SUWC  will  attend  these  briefs.  The  process  of  applying  the  intelligence  provided  at  the 
daily  briefs  in  an  attempt  to  identify  a  contact  is  completely  manual. 

7.  EXAMINE  KINEMATICS  DATA:  Kinematics  data  are 
attributes  specific  to  a  given  contact.  They  may  include,  but  are  not  limited  to,  bearing, 
speed  and  altitude.  This  information  is  provided  by  the  system,  but  the  operator  must 
understand  it  in  context  and  make  decisions  based  on  the  information  provided  and 
known  criteria.  This  process  can  be  automated  through  ID  doctrine,  but  more  often  than 
not,  it  is  conducted  by  an  operator. 

8.  OBTAIN  VISUAL  IDENTIFICATION;  When  available, 
either  a  friendly  aircraft  or  a  lookout  on  the  deck  can  provide  a  visual  identification  of  a 
contact.  This  process  is  conducted  by  an  operator  in  the  CIC  verbally  requesting  one  of 
the  aforementioned  elements  to  conduct  a  visual  scan  of  the  contact,  if  possible. 

9.  CONDUCT  VERBAL  QUERY:  A  completely  manual 
process  whereby  an  operator  in  the  CIC,  following  the  procedures  of  the  ship,  will 


36 


attempt  to  contact  the  unknown  track  via  radio  communications.  The  first  attempt  will 
most  often  be  through  an  encrypted  path,  but  if  that  fails,  an  unencrypted  channel  will  be 
used  to  gain  voice  communications.  Due  to  the  fact  that  commercial  aircraft  do  not  have 
access  to  encryption,  this  process  sequence  can  be  altered  (unencrypted  radio 
communications  before  encrypted  radio  communications)  should  the  operator  believe  the 
contact  is  a  commercial  aircraft  versus  a  friendly  military  aircraft. 
d.  Relay 

Once  a  contact  has  been  identified,  it  is  usually  disseminated  throughout 
the  battle  force.  This  process  is  conducted  in  a  controlled  manner  so  as  not  to  publish 
erroneous  track  information  and  muddle  the  operational  picture  and  situational  awareness 
of  the  battle  force. 

1.  SEND  OVER  THE  EINKS:  Once  a  contact  has  been 
identified,  the  process  of  providing  the  information  via  Eink  11  or  Eink  16  is  conducted. 
The  operator  will  determine  if  enough  information  is  provided  for  the  contact  to  be  given 
a  “friendly”  or  “hostile”  identity.  If  not  enough  information  is  provided,  the  operator 
may  determine  to  send  the  contact  out  as  an  “unknown”  and  request  additional  support  in 
identification  from  other  sources  within  the  battle  group. 

2.  DISCUSS  PICTURE  WITH  BATTEE  EORCE  UNITS: 
The  entire  track  management  process,  as  presented  so  far,  is  not  sufficient  to  provide  a 
completely  accurate  situational  awareness  of  the  operational  picture.  Different  platforms 
have  differing  assets  at  their  disposal  or  allied  vessels  may  not  possess  the  capability  to 
tie  into  the  network,  so  it  is  beneficial  to  conduct  periodic  discussions  with  the  force 
elements  to  ensure  a  common  operational  picture  is  obtained.  This  is  a  manual  process 
whereby  an  operator  verbally  communicates  with  other  elements  within  the  battle  force. 

E,  “AS  IS”  KVA  ANALYSIS 

An  analysis  of  each  watch  station  within  the  track  management  process  and  the 
associated  sub  processes  is  provided  for  both  the  AEGIS  and  SSDS  platforms  in  the 
following  tables.  The  information  provided  for  each  analysis  was  produced  through 
discussions,  video  teleconferences  and  phone  conversations  with  SME’s.  Each  category 
for  the  KVA  analysis  is  defined  below. 
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1,  Number  of  Personnel 

The  “Number  of  Personnel”  category  represents  the  number  of  sailors  and  officers 
which  are  involved  in  the  specific  sub  process.  For  purposes  of  this  research,  the  column 
will  reflect  (1)  due  to  the  fact  that  each  individual  watch  station  is  delineated  and 
provided  its  own  individual  analysis.  Were  processes  not  broken  down  by  watch  stations, 
the  number  for  this  column  would  reflect  the  total  amount  of  sailors  and  officers  required 
to  complete  the  given  process. 

2.  Actions  per  Hour 

The  “Actions  per  Hour”  reflects  the  number  of  times  each  sub  process  is  executed 
by  the  specified  watch  stander.  The  actions  are  predicated  on  the  amount  of  contacts, 
both  air  and  surface,  which  are  encountered  during  a  typical  hour  within  the  CIC.  Each 
contact  must  be  acted  upon,  hence  the  rationale  for  “actions”  versus  “contacts”  per  hour. 
The  values  were  obtained  through  querying  subject  matter  experts,  from  both  training  and 
operational  commands,  as  to  what  their  experience  has  been  with  each  sub  process.  Each 
SME  provided  an  estimate,  and  these  estimates  were  then  aggregated  to  determine  the 
average  amount  of  actions  per  hour.  Basic  assumptions  for  this  category  were: 

•  Estimates  were  to  be  determined  based  on  a  typical,  six  month  deployment 

•  The  number  of  contacts  were  determined  based  on  an  average  of  both 
open  ocean  transit  and  operations  in  the  littorals 

3.  Actual  Work  Time  (AWT) 

Each  time  a  sub  process  is  acted  upon  (as  depicted  in  the  “Actions  per  Hour” 
category)  there  is  a  specific  amount  of  time  that  is  required  to  accomplish  the  action.  The 
“AWT”  category  captures  this  data  in  hourly  units.  While  each  of  the  actions  only 
requires  a  few  seconds,  the  category  captures  the  data  in  hours  in  order  to  maintain 
continuity  of  units  of  time  throughout  the  analysis. 

4,  Total  Work  Time 

Each  of  the  sub  processes  are  acted  upon  multiple  times  during  a  given  hour  of 
operations.  The  “Total  Work  Time”  category  represents  the  total  amount  of  time  that 
each  individual  sub  process  is  acted  upon  within  an  hour.  This  category  is  derived  by 
multiplying  the  “AWT”  and  “Actions  per  Hour”  categories  together.  The  analysis  is 

given  in  hourly  units,  so  when  “Total  Work  Time”  for  each  of  the  sub  processes  are 
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added  together  for  eaeh  of  the  wateh  stations,  the  total  aggregate  should  remain  below 
1.0.  If  the  total  was  to  exeeed  1.0,  we  would  know  our  ealeulations,  or  estimates,  are 
ineorreet  as  there  is  only  1 .0  hours  for  all  the  given  sub  proeesses  to  oeeur.  Given  this,  if 
the  total  was  to  equal  1.0,  it  would  mean  that  for  any  given  hour,  100%  of  the  wateh 
station’s  time  is  devoted  to  the  sub  proeesses  depieted  in  the  analysis. 

5.  Actual  Learning  Time  (ALT) 

The  “Aetual  Learning  Time”  eategory  is  the  foeal  point  of  the  analysis.  It 
provides  the  total  amount  of  time  that  is  required  to  learn  the  given  sub  proeess. 
Learning  time  ean  be  an  aggregate  of  formal  sehools,  distanee  learning,  OJT  or  any  other 
training  experienee  that  eould  fall  within  the  loeal  eommand  definition  of  “learning”.  For 
the  purposes  of  this  analysis,  ALT  is  eomprised  of  formal  sehool  training  and  OJT 
provided  aboard  ship.  To  ensure  that  all  estimates  from  SME’s  were  eonsistent,  a 
standard  baseline  needed  to  be  provided.  The  basie  assumptions  to  aehieve  this  baseline 
are  provided  below: 

a.  Officer-SSDS 

The  baseline  for  eaeh  offieer  was  an  individual  that  had  eompleted  initial 
offieer  training,  but  had  no  prior  experienee  with  the  SSDS  platform.  Additionally,  it 
was  neeessary  to  determine  the  formal  sehools  that  would  be  represented  by  this 
eategory.  While  eaeh  sehool’s  duration  is  eonsiderably  longer  than  the  hours  represented 
in  the  “ALT”  eategory,  estimates  were  determined  based  on  the  aggregated  amount  of 
time  that  was  devoted  to  teaehing  the  given  sub  proeess  from  eaeh  sehool: 

•  SSDS  Basie  Operator  Course  of  Instruetion 

•  SSDS  Advaneed  Operator  Course  of  Instruetion 

•  SSDS  Warfare  Operator  Course  of  Instruetion 

b.  Officer-AEGIS 

The  baseline  for  eaeh  offieer  was  an  individual  that  had  eompleted  offieer 
training,  but  had  no  prior  experienee  with  the  AEGIS  platform.  Additionally,  it  was 
neeessary  to  determine  the  formal  sehools  that  would  be  represented  by  this  eategory. 
While  eaeh  sehool’ s  duration  is  eonsiderably  longer  than  the  hours  represented  in  the 
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“ALT”  category,  estimates  were  determined  based  on  the  aggregated  amount  of  time  that 
was  devoted  to  teaching  the  given  sub  proeess  from  each  school: 

•  AEGIS  Training  Course 

•  SWOS  TAG  Sehool 

•  TAG  Simulator  Training 

c.  Enlisted-SSDS 

The  baseline  for  each  sailor  was  an  individual  that  had  completed  boot 
camp,  but  had  no  prior  experience  with  the  SSDS  platform.  Additionally,  it  was 
necessary  to  determine  the  formal  schools  that  would  be  represented  by  this  category. 
While  eaeh  school’s  duration  is  considerably  longer  than  the  hours  represented  in  the 
“ALT”  category,  estimates  were  determined  based  on  the  aggregated  amount  of  time  that 
was  devoted  to  teaehing  the  given  sub  proeess  from  eaeh  sehool: 

•  GS  “A”  School 

•  SSDS  Basic  Gperator  Course  of  Instruetion 

•  SSDS  Advanced  Gperator  Course  of  Instruetion 

•  SSDS  Warfare  Gperator  Course  of  Instruetion  (E5  and  above) 

d.  Enlisted-AEGIS 

The  baseline  for  each  sailor  was  an  individual  that  had  completed  boot 
eamp,  but  had  no  prior  experience  with  the  AEGIS  platform.  Additionally,  it  was 
necessary  to  determine  the  formal  schools  that  would  be  represented  by  this  category. 
While  eaeh  school’s  duration  is  considerably  longer  than  the  hours  represented  in  the 
“ALT”  category,  estimates  were  determined  based  on  the  aggregated  amount  of  time  that 
was  devoted  to  teaching  the  given  sub  proeess  from  each  school: 

•  GS  “A”  School 

•  AEGIS  Console  Gperator  Course 
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6.  Rank  Order  (NLT) 

An  ordinal  ranking  of  the  sub  processes  provides  a  means  to  ensure  the  “ALT” 
estimates  are  reliable  and  as  accurate  as  possible.  By  allowing  the  SME’s  to  rank  order 
each  of  the  sub  processes  (1  being  the  least  complex)  outside  the  context  of  units  of  time, 
a  mathematical  correlation  can  be  calculated  between  the  “Rank  Order  (NET)”  and 
“AET”  categories.  If  a  correlation  of  .80  or  higher  is  achieved,  the  “ALT”  numbers  can 
be  considered  an  accurate  reflection  of  the  sub  processes  complexity.  Should  the 
correlation  result  in  a  number  below  .80,  “ALT”  estimates  should  be  closely  scrutinized 
and  possibly  reevaluated  after  providing  a  better  explanation  of  the  “ALT”  components  to 
the  SME’s.  It  is  possible  to  achieve  a  100%  correlation  between  rank  ordered  ordinal 
numbers  and  ration  numbers  (ALT)  due  to  the  mathematical  properties  of  the  two  scales. 

7.  Percent  Information  Technology  (%IT) 

Each  sub  process  is  represented  by  a  percentage  between  0  and  100.  This  number 
is  an  estimate  for  the  percentage  of  automation  for  each  sub  process.  This  category 
captures  the  knowledge  that  is  embedded  within  the  IT  so  that  it  can  be  accounted  for  in 
calculations  in  a  way  that  is  consistent  with  the  human  learning  time  estimates. 
Automation  is  defined  as  the  amount  of  the  sub  process  that  is  performed  by  information 
technology  systems,  and  does  not  require  the  actions  of  an  operator.  If  the  category  has 
100%,  this  would  indicate  that  the  sub  process  is  completely  automated  and  does  not 
require  a  watch  stander  to  accomplish  any  portion  of  the  task.  If  the  category  is  0%,  there 
is  no  automation  and  the  watch  stander  completes  the  entire  sub  process  manually. 
Numbers  that  fall  between  the  extremes  are  estimates  based  on  SME  observations  and 
experience. 

8.  Total  Learning  Time  (TLT) 

This  category  is  determined  by  dividing  the  “Actual  Teaming  Time”  by  the 
“Percent  Information  Technology”  category.  The  actual  formula  is  ALT/(1-%IT).  This 
calculation  provides  a  total  time  required  to  learn  the  sub  process,  to  include  that  learning 
time  which  is  resident  within  the  IT  system.  Eor  instance;  If  it  takes  2  hours  to  learn  a 
system  that  is  50%  automated,  then  the  total  learning  time  for  that  system  (to  include  the 
learning  time  that  is  embedded  in  the  system  itself)  would  be  4  hours. 
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9.  Numerator 

The  “Numerator”  eategory  deseribes  the  “percentage  of  the  revenue  or  sales 
dollar  allocated  to  the  amount  of  knowledge  required  to  obtain  the  outputs  of  a  given 
process  in  proportion  to  the  total  amount  of  knowledge  required  to  generate  the 
corporation's  salable  outputs”  (Housel  and  Bell,  2001).  The  revenue  surrogate  allocated 
to  the  amount  of  knowledge,  for  purposes  of  this  research,  is  the  amount  of  knowledge 
that  is  resident  in  the  sub  process.  To  calculate  this  category,  the  “Number  of  Personnel”, 
“Actions  per  Hour”,  and  “Total  Learning  Time”  categories  are  multiplied  together, 
providing  the  knowledge  revenue  surrogate  for  each  sub  process. 

10,  Denominator 

This  category  denotes  the  cost  associated  with  producing  the  output  of  the  sub 
process.  It  is  determined  through  multiplying  the  “Number  of  Personnel”,  “Actions  per 
Hour”  and  “Actual  Work  Time”  categories.  This  calculation  provides  the  cost  associated 
with  the  sub  process. 

11.  Return  on  Knowledge  (ROK) 

With  every  sub  process,  there  is  a  cost  and  value  (or  revenue)  associated  with 
generating  an  output.  While  these  values  and  costs  are  captured  in  the  “Numerator”  and 
“Denominator”  categories  there  needs  to  be  a  way  to  quantify  the  knowledge  embedded 
within  an  IT  system.  ROK  is  the  ratio  between  the  “Numerator”  and  “Denominator” 
categories  which  is  used  to  determine  the  value  added  by  knowledge  assets  within  a  given 
process.  The  ratio  provides  a  representation  as  to  how  well  the  knowledge  assets  in  an 
organization  are  performing  based  upon  the  value  and  cost  that  each  provides.  ROK’s 
can  be  compared  within  a  process  to  help  determine  if  knowledge  assets  are  being  used  in 
an  efficient  manner;  if  automation  could  be  inserted  to  improve  process  performance;  and 
if  processes  should  be  changed  to  promote  efficiencies.  While  ROK  is  a  valuable  tool,  a 
low  ROK  does  not  automatically  assume  a  process  is  inefficient  or  in  need  of  automation, 
but  rather  is  an  indicator  that  the  process  may  need  further  analysis  to  determine  if  it  is 
using  its  knowledge  assets  in  a  productive  manner. 

12,  “As  Is”  Process  Data 

Each  of  the  processes,  and  subsequent  sub  processes,  associated  with  the  different 
watch  stations  will  be  presented  for  evaluation.  The  methodology  of  decomposing  the 
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track  management  process  based  upon  each  watch  station  provides  a  more 
comprehensive  look  at  the  value  associated  with  eaeh  wateh  station  for  each  platform 
(AEGIS,  SSDS). 


Each  of  the  following  analyses  presents  aggregated  data  as  provided  by  SME’s. 
The  resulting  ROK’s  were  used  to  focus  attention  to  discrepaneies  and  differenees 
between  the  proeesses.  Through  an  analysis  of  the  “As  Is”  data,  a  better  understanding 
was  gained  as  to  use  of  knowledge  assets  within  in  eaeh  process. 

a.  AEGIS  Tactical  Action  Officer  Analysis 

Table  6  depiets  the  traek  management  eore  proeesses  involved  in  the  KVA 
analysis  for  a  TAO  aboard  an  AEGIS  platform. 


Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per  AWT 
Hour  (Hours) 

Total  Work  Time 
per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

HUM 

DEN  ROK 

Tactical  Action  Officer  (TAO) 

CORRELATE 

Obtain  Link  Information 

128  0.00028 

0.03556 

24.0 

2.0 

95S 

480.0 

61440.0 

0.0  1728.0 

Identify  "Same  Contact.  Multiple  Track" 

40  0.00194 

0.07778 

24.0 

1.0 

20S 

30.0 

1200.0 

0.1  15.4 

Verify  Other  Track  Sources 

20  0.00194 

0.03889 

30.0 

3.0 

20% 

37.5 

750.0 

0.0  19.3 

Correl  * 

0.87 

63390.0 

0.2  416.4 

TRACK 

Monitor  Suspect  Tracks 

25  0.00194 

0.04861 

12.0 

3.0 

20% 

15.0 

375.0 

0.0  7.7 

Update  Tracks 

1  10  0.00194 

0.01944 

6.0 

2.0 

30% 

8.6 

85.7 

0.0  4.4 

Uodate  GCCS-M 

1  2  0.00139 

0.00278 

6.0 

1.0 

60% 

15.0 

30.0 

0.0  10.8 

Correl  = 

0.87 

490.7 

0.1  6.9 

IDENTIFY 

Venfy  FF  signal 

128  0.00028 

0.03556 

24.0 

8.0 

95% 

480.0 

61440.0 

0.0  1728.0 

Verify  EW  emissions 

1  25  0.00139 

0.03472 

18.0 

5.0 

50% 

36.0 

900.0 

0.0  25.9 

Verify  Point  of  Origin 

12  0.00278 

0.03333 

6.0 

3.0 

0% 

6.0 

72.0 

0.0  2.2 

Match  Against  ATO 

20  0.00278 

0.05556 

6.0 

6.0 

0% 

6.0 

120.0 

0.1  2.2 

Match  Against  CommAir  Proffle 

1  25  0.00028 

0.00694 

6.0 

4.0 

95% 

120.0 

3000.0 

0.0  432.0 

Match  Against  Intel  Information 

25  0.00278 

0.06944 

30.0 

9.0 

0% 

30.0 

750.0 

0.1  10.8 

Examine  Kinematic  Data 

25  0.00139 

0.03472 

12.0 

7.0 

50% 

24.0 

600.0 

0.0  17.3 

Obtain  Visual  D 

1  5  0.00278 

0.01389 

6.0 

1.0 

0% 

6.0 

30.0 

0.0  2.2 

Conduct  Verbal  Query 

1  9  0.00278 

0.02500 

6.0 

2.0 

0% 

6.0 

54.0 

0.0  2.2 

Correl  * 

0.80 

66966.0 

0.3  216.6 

RELAY 

Send  Over  Links 

S  0.00083 

0.00417 

6.0 

1.0 

80% 

30.0 

150.0 

0.0  36.0 

Discuss  Picture  with  Battle  Force  Units 

1  15  0.00278 

0.04167 

12.0 

2.0 

0% 

12.0 

180.0 

0.0  4.3 

0.57806 

Correl » 

1.00 

330.0 

0.0  7.2 

Table  6.  “As  Is”  AEGIS  TAO  KVA  Analysis 


b.  SSDS  Tactical  Action  Officer  Analysis 

Table  7  depicts  the  track  management  eore  proeesses  involved  in  the  KVA 
analysis  for  a  TAO  aboard  an  SSDS  platform. 
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Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per 
Hour 

AWT  Total  Work 
(Hours)  Time  per  Hr 

ALT 

(Hours) 

NLT 

IT% 

TLT 

(Hours) 

NUM  DEN 

ROK 

Tactical  Action  Officer  (TAO) 

CORRELATE 

Obtain  Link  Information 

128 

0.00028  0.03556 

8.0 

2.0 

95% 

160.0 

20480.0  0.03556 

576.0 

Identify  "Same  Contact,  Multiple  Track" 

40 

0.00194  0.07778 

8.0 

1.0 

20% 

10.0 

400.0  0.07778 

5.1 

Verify  Other  Track  Sources 

20 

0.00194  0.03889 

10.0 

3.0 

20% 

12.5 

250.0  0.03889 

6.4 

Correl  = 

0.87 

21130.0  0.15222 

138.8 

TRACK 

Monitor  Suspect  Tracks 

25 

0.00194  0.04861 

4.0 

3.0 

20% 

5.0 

125.0  0.04861 

2.6 

Update  Tracks 

10 

0.00194  0.01944 

2.0 

2.0 

30% 

2.9 

28.6  0.01944 

1.5 

Update  GCCS-M 

2 

0.00139  0.00278 

2.0 

1.0 

60% 

5.0 

10.0  0.00278 

3.6 

Correl  = 

0.87 

163.6  0.07083 

2.3 

IDENTIFY 

Verify  FF  signal 

128 

0.00028  0.03556 

8.0 

8.0 

95% 

160.0 

20480.0  0.03556 

576.0 

Verify  EW  emissions 

25 

0.00139  0.03472 

6.0 

5.0 

50% 

12.0 

300.0  0.03472 

8.6 

Verify  Point  of  Origin 

12 

0.00278  0.03333 

2.0 

3.0 

0% 

2.0 

24.0  0.03333 

0.7 

Match  Against  ATO 

20 

0.00278  0.05556 

2.0 

6.0 

0% 

2.0 

40.0  0.05556 

0.7 

Match  Against  CommAir  Profile 

25 

0.00028  0.00694 

2.0 

4.0 

95% 

40.0 

1000.0  0.00694 

144.0 

Match  Aaainst  Intel  Information 

25 

0.00278  0.06944 

10.0 

9.0 

0% 

10.0 

250.0  0.06944 

3.6 

Examine  Kinematic  Data 

25 

0.00139  0.03472 

4.0 

7.0 

50% 

8.0 

200.0  0.03472 

5.8 

Obtain  Visual  0 

5 

0.00278  0.01389 

2.0 

1.0 

0% 

2.0 

10.0  0.01389 

0.7 

Conduct  Verbal  Query 

9 

0.00278  0.02500 

2.0 

2.0 

0% 

2.0 

18.0  0.02500 

0.7 

Correl » 

0.80 

22322.0  0.30917 

72.2 

RELAY 

Send  Over  Links 

5 

0.00083  0.00417 

2.0 

1.0 

80% 

10.0 

50.0  0.00417 

12.0 

Discuss  Picture  with  Battle  Force  Units 

15 

0.00278  0.04167 

4.0 

2.0 

0% 

4.0 

60.0  0.04167 

1.4 

519 

0.03028  0.57806 

Correl  * 

1.00 

447.4 

110.0  0.04583 

2.4 

Table  7.  “As  Is”  SSDS  TAO  KVA  Analysis 


c.  AEGIS  Anti-Air  Warfare  Coordinator  Analysis 
Table  8  depicts  the  track  management  core  processes  involved  in  the  KVA 
analysis  for  an  AAWC  aboard  an  AEGIS  platform. 


Billet 

Humber  of 

Contact  ID  Subprocess  Personnel 

Actions  per 
Hour 

AWT 

(Hours) 

Total  Work  Time 
per  Hr 

ALT 

(Hours) 

NLT 

rr% 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Anti  Air  Warfare  Coordinator  (AAWC) 

CORRELATE 

Obtain  Link  Information 

128 

0.00028 

0.03556 

24.0 

2.0 

95% 

480.0 

61440.0 

0.0 

1728.0 

identify  'Same  Contact.  Multple  Track" 

40 

0.00194 

0.07778 

24.0 

1.0 

20% 

30.0 

1200.0 

0.1 

15.4 

Verify  Other  Track  Sources 

20 

0.00194 

0.03889 

30.0 

3.0 

20% 

37.5 

750.0 

0.0 

19.3 

Correl  = 

0.87 

63390.0 

0.2 

416.4 

TRACK 

Monitor  Suspect  Tracks 

25 

0.00194 

0.04861 

12.0 

2.0 

20% 

15.0 

375.0 

0.0 

7.7 

Update  Tracks 

30 

0.00194 

0.05833 

6.0 

1.0 

30% 

8.6 

257.1 

0.1 

4.4 

Correl  = 

1.00 

632.1 

0.1 

5.9 

IDENTIFY 

Verify  IFF  signal 

128 

0.00028 

0.03556 

24.0 

8.0 

95% 

480.0 

61440.0 

0.0 

1728.0 

Verify  EW  emissions 

25 

0.00139 

0.03472 

18.0 

5.0 

50% 

36.0 

900.0 

0.0 

25.9 

Verify  Point  of  Origin 

12 

0.00278 

0.03333 

6.0 

3.0 

0% 

6.0 

72.0 

0.0 

2.2 

Match  Against  ATO 

20 

0.00278 

0.05556 

6.0 

6.0 

0% 

6.0 

120.0 

0.1 

2.2 

Match  Against  CommAir  Profile 

128 

0.00028 

0.03556 

6.0 

4.0 

95% 

120.0 

15360.0 

0.0 

432.0 

Match  Against  Intel  Information 

25 

0.00278 

0.06944 

30.0 

9.0 

0% 

30.0 

750.0 

0.1 

10.8 

Examine  Kinematic  Data 

50 

0.00139 

0.06944 

12.0 

7.0 

50% 

24.0 

1200.0 

0.1 

17.3 

Obtain  Visual  ID 

5 

0.00278 

0.01389 

6.0 

1.0 

0% 

6.0 

30.0 

0.0 

2.2 

Conduct  Verbal  Query 

9 

0.00278 

0.02500 

6.0 

2.0 

0% 

6.0 

54.0 

0.0 

2.2 

Correl  = 

0.80 

79926.0 

0.4 

214.6 

RELAY 

Send  Over  Links 

5 

0.00083 

0.00417 

6.0 

1.0 

80% 

30.0 

150.0 

0.0 

36.0 

Discuss  Picture  with  Battle  Force  Units 

50 

0.00278 

0.13889 

12.0 

2.0 

0% 

12.0 

600.0 

0.1 

4.3 

0.77472 

Correl  = 

1.00 

750.0 

0.1 

5.2 

Table  8.  “As  Is”  AEGIS  AAWC  KVA  Analysis 


d.  SSDS  Anti-Air  Warfare  Coordinator  Analysis 

Table  9  depicts  the  track  management  core  processes  involved  in  the  KVA 
analysis  for  an  AAWC  aboard  an  SSDS  platform. 
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Billet 

Number  of  Actions  per 

Contact  ID  Subprocess  Personnel  Hour 

AWT 

(Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT 

IT% 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Anti  Air  Warfare  Coordinator  (AAWC) 

CORRELATE 

Obtain  Link  Information 

1  128 

0.00028 

0.03556 

8.0 

2.0 

95% 

160.0 

20480.0 

0.03556 

576.0 

Identify  "Same  Contact,  Multiple  Track" 

1  40 

0.00194 

0.07778 

8.0 

1.0 

20% 

10.0 

400.0 

0.07778 

5.1 

Verify  Other  Track  Sources 

1  20 

0.00194 

0.03889 

10.0 

3.0 

20% 

12.5 

250.0 

0.03889 

6.4 

Correl  * 

0.87 

21130.0 

0.15222 

138.8 

TRACK 

Monitor  Suspect  Tracks 

1  25 

0.00194 

0.04861 

4.0 

2.0 

20% 

5.0 

125.0 

0.04861 

2.6 

Uodate  Tracks 

1  30 

0.00194 

0.05833 

2.0 

1.0 

30% 

2.9 

85.7 

0.05833 

1.5 

Correl  = 

1.00 

210.7 

0.10694 

2.0 

IDENTIFY 

Verify  FF  signal 

1  128 

0.00028 

0.03556 

8.0 

8.0 

95% 

160.0 

20480.0 

0.03556 

576.0 

Verify  EW  emissions 

1  25 

0.00139 

0.03472 

6.0 

5.0 

50% 

12.0 

300.0 

0.03472 

8.6 

Verify  Point  of  Origin 

1  12 

0.00278 

0.03333 

2.0 

3.0 

0% 

2.0 

24.0 

0.03333 

0.7 

Match  Against  ATO 

1  20 

0.00278 

0.05556 

2.0 

6.0 

0% 

2.0 

40.0 

0.05556 

0.7 

Match  Against  CommAir  Profile 

1  128 

0.00028 

0.03556 

2.0 

4.0 

95% 

40.0 

5120.0 

0.03556 

144.0 

Match  Against  Intel  Information 

1  25 

0.00278 

0.06944 

10.0 

9.0 

0% 

10.0 

250.0 

0.06944 

3.6 

Examine  Kinematic  Data 

1  50 

0.00139 

0.06944 

4.0 

7.0 

50% 

8.0 

400.0 

0.06944 

5.8 

Obtain  Visual  D 

1  5 

0.00278 

0.01389 

2.0 

1.0 

0% 

2.0 

10.0 

0.01389 

0.7 

Conduct  Verbal  Query 

1  9 

0.00278 

0.02500 

2.0 

2.0 

0% 

2.0 

18.0 

0.02500 

0.7 

Correl  = 

0.80 

26642.0 

0.37250 

71.5 

RELAY 

Send  Over  Links 

1  5 

0.00083 

0.00417 

2.0 

1.0 

80% 

10.0 

50.0 

0.00417 

12.0 

Discuss  Picture  with  Battle  Force  Units 

1  50 

0.00278 

0.13889 

4.0 

2.0 

0% 

4.0 

200.0 

0.13889 

1.4 

0.77472 

Correl  * 

1.00 

250.0 

0.14306 

1.7 

Table  9.  “As  Is”  SSDS  AAWC  KVA  Analysis 
e.  AEGIS  Surface  Warfare  Coordinator 

Table  10  depiets  the  traek  management  eore  proeesses  involved  in  the 
KVA  analysis  for  an  SUWC  aboard  an  AEGIS  platform. 


Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per 
Hour 

AWT 

(Hours) 

Total  Work  Time 
per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Surtax  Warfare  Coordinator  (SUWC) 

CORRELATE 

Obtain  Link  Information 

64 

0.00028 

0.01778 

24.0 

2.0 

95% 

480.0 

30720.0 

0.0 

1728.0 

Identify  "Same  Contact.  Multiple  Track" 

2 

0.00194 

0.00389 

24.0 

1.0 

20% 

30.0 

60.0 

0.0 

15.4 

Verify  Other  Track  Sources 

20 

0.00194 

0.03889 

30.0 

3.0 

20% 

37.5 

750.0 

0.0 

19.3 

Correl  = 

0.87 

31530.0 

0.1 

520.7 

TRACK 

Monkor  Suspect  Tracks 

1 

0.00194 

0.00194 

12.0 

3.0 

20% 

15.0 

15.0 

0.0 

7.7 

Update  Tracks 

10 

0.00194 

0.01944 

6.0 

2.0 

30% 

8.6 

85.7 

0.0 

4.4 

Uodate  GCCS-M 

20 

0.00139 

0.02778 

6.0 

1.0 

60% 

15.0 

300.0 

0.0 

10.8 

Correl  = 

0.87 

400.7 

0.0 

8.2 

IDENTIFY 

Verify  IFF  signal 

6 

0.00028 

0.00167 

24.0 

6.0 

95% 

480.0 

2880.0 

0.0 

1728.0 

Verify  EW  emissions 

15 

0.00139 

0.02083 

18.0 

4.0 

50% 

36.0 

540.0 

0.0 

25.9 

Verify  Point  of  Origin 

1 

0.00278 

0.00278 

6.0 

3.0 

0% 

6.0 

6.0 

0.0 

2.2 

Match  Against  Intel  Information 

5 

0.00278 

0.01389 

30.0 

7.0 

0% 

30.0 

150.0 

0.0 

10.8 

Examine  Kinematic  Data 

64 

0.00139 

0.08889 

12.0 

5.0 

50% 

24.0 

1536.0 

0.1 

17.3 

Obtan  Visual  D 

5 

0.00278 

0.01389 

6.0 

1.0 

0% 

6.0 

30.0 

0.0 

2.2 

Conduct  Verbal  Query 

9 

0.00278 

0.02500 

6.0 

2.0 

0% 

6.0 

54.0 

0.0 

2.2 

Correl  * 

0.91 

5196.0 

0.2 

31.1 

RELAY 

Send  Over  Links 

1 

0.00083 

0.00083 

6.0 

1.0 

80% 

30.0 

30.0 

0.0 

36.0 

Discuss  Picture  with  Battle  Force  Units 

5 

0.00278 

0.01389 

12.0 

2.0 

0% 

12.0 

60.0 

0.0 

4.3 

0.29139 

Correl  = 

1.00 

90.0 

0.0 

6.1 

Table  10.  “As  Is”  AEGIS  SUWC  KVA  Analysis 
f  SSDS  Surface  Warfare  Coordinator 

Table  11  depiets  the  traek  management  eore  proeesses  involved  in  the 
KVA  analysis  for  an  SUWC  aboard  an  SSDS  platform. 
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Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per 
Hour 

AWT 

(Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT  IT% 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Surface  Warfare  Coordinator  (SUWC) 

CORRELATE 

Obtain  Link  Information 

64 

0.00028 

0.01778 

8.0 

2.0  95% 

160.0 

10240.0 

0.01778 

576.0 

Identify  "Same  Contact.  Multiple  Track" 

2 

0.00194 

0.00369 

8.0 

1.0  20% 

10.0 

20.0 

0.00389 

5.1 

Verify  Other  Track  Sources 

20 

0.00194 

0.03889 

10.0 

3.0  20% 

12.5 

250.0 

0.03889 

6.4 

Correl  = 

0.87 

10510.0 

0.06056 

173.6 

TRACK 

Monitor  Suspect  Tracks 

1 

0.00194 

0.00194 

4.0 

3.0  20% 

5.0 

5.0 

0.00194 

2.6 

Update  Tracks 

10 

0.00194 

0.01944 

2.0 

2.0  30% 

2.9 

28.6 

0.01944 

1.5 

Uodate  GCCS-M 

20 

0.00139 

0.02778 

2.0 

1.0  60% 

5.0 

100.0 

0.02778 

3.6 

Correl  * 

0.87 

133.6 

0.04917 

2.7 

IDENTIFY 

Verify  IFF  signal 

6 

0.00028 

0.00167 

8.0 

6.0  95% 

160.0 

960.0 

0.00167 

576.0 

Verify  EW  emissions 

1  15 

0.00139 

0.02083 

6.0 

4.0  50% 

12.0 

180.0 

0.02083 

8.6 

Verify  Point  of  Origin 

1  1 

0.00278 

0.00278 

2.0 

3.0  0% 

2.0 

2.0 

0.00278 

0.7 

Match  Against  Intel  Information 

1  5 

0.00278 

0.01389 

10.0 

7.0  0% 

10.0 

50.0 

0.01389 

3.6 

Examine  Kinematic  Data 

1  64 

0.00139 

0.08889 

4.0 

5.0  50% 

8.0 

512.0 

0.08889 

5.8 

Obtain  Visual  D 

1  5 

0.00278 

0.01389 

2.0 

1.0  0% 

2.0 

10.0 

0.01389 

0.7 

Conduct  Verbal  Query 

1  9 

0.00278 

0.02500 

2.0 

2.0  0% 

2.0 

18.0 

0.02500 

0.7 

Correl  * 

0.91 

1732.0 

0.16694 

10.4 

RELAY 

Send  Over  Links 

1 

0.00083 

0.00083 

2.0 

1.0  80% 

10.0 

10.0 

0.00083 

12.0 

Discuss  Picture  with  Battle  Force  Units 

1  5 

0.00278 

0.01389 

4.0 

2.0  0% 

4.0 

20.0 

0.01389 

1.4 

0.29139 

Correl  * 

1.00 

30.0 

0.01472 

2.0 

Table  1 1 .  “As  Is”  SSDS  SUWC  KVA  Analysis 
g.  AEGIS  Combat  Systems  Coordinator 

Table  12  depicts  the  track  management  core  processes  involved  in  the 
KVA  analysis  for  a  CSC  aboard  an  AEGIS  platform. 


Billet 

Number  of 

Cwitact  ID  Sut^rocess  Personnel 

Actions  per 
Hour 

AWT  Total  Work  Time 
(Hours)  per  Hr 

ALT 

(Hours) 

NLT 

IT% 

TLT 

(Hours) 

NUM  DEN 

ROK 

Combat  Systems  Coordinator  (CSC) 

CORRELATE 

Obtain  Link  Information 

128 

0.00028  0.03556 

6.0 

2.0 

95% 

120.0 

15360.0  0.0 

432.0 

Identify  "Same  Contact,  Multiple  Track" 

40 

0.00194  0.07778 

6.0 

1.0 

20% 

7.5 

300.0  0.1 

3.9 

Verify  Other  Track  Sources 

20 

0.00194  0.03889 

8.0 

3.0 

20% 

10.0 

200.0  0.0 

5.1 

Correl  * 

0.87 

15860.0  0.2 

104.2 

TRACK 

Monitor  Suspect  Tracks 

25 

0.00194  0.04861 

3.0 

2.0 

20% 

3.8 

93.8  0.0 

1.9 

Uodate  Trades 

10 

0.00194  0.01944 

2.0 

1.0 

30% 

2.9 

28.6  0.0 

1.5 

Correl  * 

1.00 

122.3  0.1 

1.8 

IDENTIFY 

Verify  FF  signal 

10 

0.00028  0.00278 

6.0 

6.0 

95% 

120.0 

1200.0  0.0 

432.0 

Verify  EW  emissions 

25 

0.00139  0.03472 

5.0 

3.0 

50% 

10.0 

250.0  0.0 

7.2 

Verify  Point  of  Origin 

1 

0.00278  0.00278 

2.0 

1.0 

0% 

2.0 

2.0  0.0 

0.7 

Match  Against  ATO 

2 

0.00278  0.00556 

2.0 

4.0 

0% 

2.0 

4.0  0.0 

0.7 

Match  Against  CommAir  Profile 

128 

0.00028  0.03556 

2.0 

2.0 

95% 

40.0 

5120.0  0.0 

144.0 

Match  Against  Intel  Information 

25 

0.00278  0.06944 

10.0 

7.0 

0% 

10.0 

250.0  0.1 

3.6 

Examine  Kinematic  Data 

1  50 

0.00139  0.06944 

4.0 

5.0 

50% 

8.0 

400.0  0.1 

5.8 

Correl  = 

0.81 

7226.0  0.2 

32.8 

RELAY 

Send  Over  Links 

1  1 

0.00083  0.00083 

2.0 

1.0 

80% 

10.0 

10.0  0.0 

12.0 

0.44139 

Correl  = 

1.00 

10.0  0.0 

12.0 

Table  12.  “As  Is”  AEGIS  CSC  KVA  Analysis 


h.  SSDS  Combat  Systems  Coordinator 

Table  13  depicts  the  track  management  core  processes  involved  in  the 
KVA  analysis  for  a  CSC  aboard  an  SSDS  platform. 


46 


Billet 

Number  of 

Contact  ID  Suk^rocess  Personnel 

Actions  per 
Hour 

Am 

(Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Coft*at  Systems  Coordinator  (CSC) 

CORRELATE 

Obtain  Link  Information 

128 

0.00028 

0.03556 

8.0 

2.0 

95% 

160.0 

20480.0 

0.03556 

576.0 

Identify  "Same  Contact,  Multiple  Track" 

40 

0.00194 

0.07778 

8.0 

1.0 

20% 

10.0 

400.0 

0.07778 

5.1 

Verify  Other  Track  Sources 

20 

0.00194 

0.03889 

10.0 

3.0 

20% 

12.5 

250.0 

0.03889 

6.4 

Correl  = 

0.87 

21130.0 

0.15222 

138.8 

TRACK 

Monitor  Suspect  Tracks 

25 

0.00194 

0.04861 

4.0 

2.0 

20% 

5.0 

125.0 

0.04861 

26 

Update  Tracks 

10 

0.00194 

0.01944 

2.0 

1.0 

30% 

2.9 

28.6 

0.01944 

1.5 

Correl  = 

1.00 

153.6 

0.06806 

2.3 

IDENTIFY 

Verify  FF  signal 

10 

0.00028 

0.00278 

8.0 

6.0 

95% 

160.0 

1600.0 

0.00278 

576.0 

Verify  EW  emissions 

25 

0.00139 

0.03472 

6.0 

3.0 

50% 

12.0 

300.0 

0.03472 

8.6 

Verify  Point  of  Orwin 

1 

0.00278 

0.00278 

2.0 

1.0 

0% 

2.0 

2.0 

0.00278 

0.7 

Match  Against  ATO 

2 

0.00278 

0.00556 

2.0 

4.0 

0% 

2.0 

4.0 

0.00556 

0.7 

Match  Against  CommAir  Profile 

128 

0.00028 

0.03556 

2.0 

2.0 

95% 

40.0 

5120.0 

0.03556 

144.0 

Match  Agakist  Intel  Information 

25 

0.00278 

0.06944 

10.0 

7.0 

0% 

10.0 

250.0 

0.06944 

3.6 

Examine  Kinematic  Data 

50 

0.00139 

0.06944 

4.0 

5.0 

50% 

8.0 

400.0 

0.06944 

5.8 

Correl  = 

0.81 

7676.0 

0.22028 

34.8 

RELAY 

Send  Over  Links 

1 

0.00083 

0.00083 

2.0 

1.0 

80% 

10.0 

10.0 

0.00083 

12.0 

0.44139 

Correl « 

1.00 

10.0 

0.00033 

12.0 

Table  13.  “As  Is”  SSDS  CSC  KVA  Analysis 


L  AEGIS  Tactical  Information  Coordinator 

Table  14  depicts  the  track  management  core  processes  involved  in  the 
KVA  analysis  for  a  TIC  aboard  an  AEGIS  platform. 


Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per  Am 
Hour  (Hours) 

Total  Work  Time 
per  Hr 

ALT 

(Hours) 

NLT  rr% 

TLT 

(Hours) 

NUM  DEN 

ROK 

Tactical  Information  Coordinator  (TIC) 

CORRELATE 

Obtain  Link  Information 

128  0.00028 

0.03556 

8.0 

2.0  95% 

160.0 

20480.0  0.0 

576.0 

Identify  'Same  Contact.  Multple  Track" 

40  0.00194 

0.07778 

8.0 

1.0  20% 

10.0 

400.0  0.1 

5.1 

Verify  Other  Track  Sources 

20  0.00194 

0.03889 

10.0 

3.0  20% 

12.5 

250.0  0.0 

6.4 

Correl  * 

0.87 

21130.0  0.2 

138.8 

TRACK 

Monitor  Suspect  Tracks 

25  0.00194 

0.04861 

4.0 

2.0  20% 

5.0 

125.0  0.0 

2.6 

Uodate  Tracks 

64  0.00194 

0.12444 

2.0 

1.0  30% 

2.9 

182.9  0.1 

1.5 

Correl  * 

1.00 

307.9  0.2 

1.8 

IDENTIFY 

Verify  IFF  signal 

182  0.00028 

0.05056 

8.0 

8.0  95% 

160.0 

29120.0  0.1 

576.0 

Verify  EW  emissions 

25  0.00139 

0.03472 

6.0 

5.0  50% 

12.0 

300.0  0.0 

8.6 

Verify  Point  of  Origin 

12  0.00278 

0.03333 

2.0 

3.0  0% 

2.0 

24.0  0.0 

0.7 

Match  Against  ATO 

20  0.00278 

0.05556 

2.0 

6.0  0% 

2.0 

40.0  0.1 

0.7 

Match  Against  CommAr  Profile 

182  0.00028 

0.05056 

2.0 

4.0  95% 

40.0 

7280.0  0.1 

144.0 

Match  Against  Intel  Information 

25  0.00278 

0.06944 

10.0 

9.0  0% 

10.0 

250.0  0.1 

3.6 

Examine  Kinematic  Data 

100  0.00139 

0.13889 

4.0 

7.0  50% 

8.0 

800.0  0.1 

5.8 

Obtain  Visual  D 

5  0.00278 

0.01389 

2.0 

1.0  0% 

2.0 

10.0  0.0 

0.7 

Conduct  Verbal  Query 

9  0.00278 

0.02500 

2.0 

2.0  0% 

2.0 

18.0  0.0 

0.7 

Correl  * 

0.80 

37842.0  0.5 

80.2 

RELAY 

Send  Over  Links 

5  0.00083 

0.00417 

2.0 

1.0  80% 

10.0 

50.0  0.0 

12.0 

Discuss  Picture  with  Battle  Force  Units 

25  0.00278 

0.06944 

4.0 

2.0  0% 

4.0 

100.0  0.1 

1.4 

0.87083 

Correl  = 

1.00 

150.0  0.1 

2.0 

Table  14.  “As  Is”  AEGIS  TIC  KVA  Analysis 


j.  SSDS  Tactical  Information  Coordinator 

Table  15  depicts  the  track  management  core  processes  involved  in  the 
KVA  analysis  for  a  TIC  aboard  an  SSDS  platform. 


47 


Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per 
Hour 

Am 

(Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Tactical  Information  Coordinator  (TIC) 

CORRELATE 

Obtain  Link  Information 

128 

0.00028 

0.03556 

8.0 

2.0 

95% 

160.0 

20480.0 

0.03556 

576.0 

Identify  ’Same  Contact,  Muliple  Track" 

40 

0.00194 

0.07778 

8.0 

1.0 

20% 

10.0 

400.0 

0.07778 

5.1 

Verify  Other  Track  Sources 

20 

0.00194 

0.03889 

10.0 

3.0 

20% 

12.5 

250.0 

0.03889 

6.4 

Correl  * 

0.87 

21130.0 

0.15222 

138.8 

TRACK 

Monitor  Suspect  Tracks 

25 

0.00194 

0.04861 

4.0 

2.0 

20% 

5.0 

125.0 

0.04861 

2.6 

Update  Tracks 

64 

0.00194 

0.12444 

2.0 

1.0 

30% 

2.9 

182.9 

0.12444 

1.5 

Correl « 

1.00 

307.9 

0.17306 

1.8 

IDENTIFY 

Verify  FF  signal 

182 

0.00028 

0.05056 

8.0 

8.0 

95% 

160.0 

29120.0 

0.05056 

576.0 

Verify  EW  emissions 

25 

0.00139 

0.03472 

6.0 

5.0 

50% 

12.0 

300.0 

0.03472 

8.6 

Verify  Point  of  Origin 

12 

0.00278 

0.03333 

2.0 

3.0 

0% 

2.0 

24.0 

0.03333 

0.7 

Match  AoainstATO 

20 

0.00278 

0.05556 

2.0 

6.0 

0% 

2.0 

40.0 

0.05556 

0.7 

Match  Against  CommAir  Profile 

182 

0.00028 

0.05056 

2.0 

4.0 

95% 

40.0 

7280.0 

0.05056 

144.0 

Match  Against  Intel  Information 

25 

0.00278 

0.06944 

10.0 

9.0 

0% 

10.0 

250.0 

0.06944 

3.6 

Examine  Kinematic  Data 

100 

0.00139 

0.13889 

4.0 

7.0 

50% 

8.0 

800.0 

0.13889 

5.8 

Obtain  Visual  D 

5 

0.00278 

0.01389 

2.0 

1.0 

0% 

2.0 

10.0 

0.01389 

0.7 

Conduct  Verbal  Query 

9 

0.00278 

0.02500 

2.0 

2.0 

0% 

2.0 

18.0 

0.02500 

0.7 

Correl  = 

0.80 

37842.0 

0.47194 

80.2 

RELAY 

Send  Over  Links 

5 

0.00083 

0.00417 

2.0 

1.0 

80% 

10.0 

50.0 

0.00417 

12.0 

Discuss  Picture  with  Battle  Force  Unks 

25 

0.00278 

0.06944 

4.0 

2.0 

0% 

4.0 

100.0 

0.06944 

1.4 

0.87083 

Correl  * 

1.00 

150.0 

0.07361 

2.0 

Table  15.  “As  Is”  SSDS  TIC  KVA  Analysis 


k.  AEGIS  Identification  Supervisor 

Table  16  depicts  the  track  management  core  processes  involved  in  the 
KVA  analysis  for  an  IDS  aboard  an  AEGIS  platform. 


Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per 
Hour 

AWT 

(Hours) 

Total  Work  Time 
per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Identification  Supervisor  (DS) 

CORRELATE 

Obtain  Link  Information 

1  128 

0.00028 

0.03556 

8.0 

2.0 

95% 

160.0 

20480.0 

0.0 

576.0 

Identify  "Same  Contact,  Multiple  Track" 

40 

0.00194 

0.07778 

8.0 

1.0 

20% 

10.0 

400.0 

0.1 

5.1 

Verify  Other  Track  Sources 

20 

0.00194 

0.03389 

10.0 

3.0 

20% 

12.5 

250.0 

0.0 

6.4 

Correl  * 

0.87 

21130.0 

0.2 

138.8 

TRACK 

Montor  Suspect  Tracks 

25 

0.00194 

0.04861 

4.0 

2.0 

20% 

5.0 

125.0 

0.0 

2.6 

Uodate  Tracks 

1  64 

0.00194 

0.12444 

2.0 

1.0 

30% 

2.9 

182.9 

0.1 

1.5 

Correl  * 

1.00 

307.9 

0.2 

1.8 

IDENTIFY 

Verify  FF  signal 

182 

0.00028 

0.05056 

8.0 

8.0 

95% 

160.0 

29120.0 

0.1 

576.0 

Verify  EW  emissions 

25 

0.00139 

0.03472 

6.0 

5.0 

50% 

12.0 

300.0 

0.0 

8.6 

Verify  Point  of  Origin 

12 

0.00278 

0.03333 

2.0 

3.0 

0% 

2.0 

24.0 

0.0 

0.7 

Match  Against  ATO 

1  20 

0.00278 

0.05556 

2.0 

6.0 

0% 

2.0 

40.0 

0.1 

0.7 

Match  Against  CommAir  Profile 

1  182 

0.00028 

0.05056 

2.0 

4.0 

95% 

40.0 

7280.0 

0.1 

144.0 

Match  Against  Intel  Information 

1  10 

0.00278 

0.02778 

10.0 

9.0 

0% 

10.0 

100.0 

0.0 

3.6 

Examine  Knematic  Data 

1  105 

0.00139 

0 14583 

4.0 

7.0 

50% 

8.0 

840.0 

0.1 

5.8 

Obtain  Veual  D 

1  5 

0.00278 

0.01389 

2.0 

1.0 

0% 

2.0 

10.0 

0.0 

0.7 

Conduct  Verbal  Query 

1  9 

0.00278 

0.02500 

2.0 

2.0 

0% 

2.0 

18.0 

0.0 

0.7 

Correl  * 

0.80 

37732.0 

0.4 

86.3 

RELAY 

Send  Over  Links 

1  64 

0.00083 

0.05333 

2.0 

1.0 

80% 

10.0 

640.0 

0.1 

12.0 

Discuss  Picture  with  Battle  Force  Units 

1  64 

0.00278 

0.17778 

4.0 

2.0 

0% 

4.0 

256.0 

0.2 

1.4 

0.99361 

Correl  = 

1.00 

896.0 

0.2 

3.9 

Table  16.  “As  Is”  AEGIS  IDS  KVA  Analysis 


I  SSDS  Identification  Supervisor 

Table  17  depicts  the  track  management  core  processes  involved  in  the 
KVA  analysis  for  an  IDS  aboard  an  SSDS  platform. 
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Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per 
Hour 

Am  Total  Work 
(Hours)  Time  per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM  DEN 

ROK 

Identification  Supervisor  (DS) 

CORRELATE 

Obtain  Link  Information 

128 

0.00028  0.03556 

8.0 

2.0 

95% 

160.0 

20480.0  0.03556 

576.0 

Identify  "Same  Contact,  Multiple  TracIC 

40 

0.00194  0.07778 

8.0 

1.0 

20% 

10.0 

400.0  0.07778 

5.1 

Verify  Other  Track  Sources 

20 

0.00194  0.03889 

10.0 

3.0 

20% 

12.5 

250.0  0.03889 

6.4 

Correl  = 

0.87 

21130.0  0.15222 

138.8 

TRACK 

Monitor  Suspect  Tracks 

25 

0.00194  0.04861 

4.0 

2.0 

20% 

5.0 

125.0  0.04861 

2.6 

Update  Tracks 

64 

0.00194  0.12444 

2.0 

1.0 

30% 

2.9 

182.9  0.12444 

1.5 

Correl  = 

1.00 

307.9  0.17306 

1.8 

IDENTIFY 

Verify  FF  signal 

182 

0.00028  0.05056 

8.0 

8.0 

95% 

160.0 

29120.0  0.05056 

576.0 

Verify  EW  emissions 

25 

0.00139  0.03472 

6.0 

5.0 

50% 

12.0 

300.0  0.03472 

8.6 

Verify  Point  of  Origin 

12 

0.00278  0.03333 

2.0 

3.0 

0% 

2.0 

24.0  0.03333 

0.7 

Match  Against  ATO 

20 

0.00278  0.05556 

2.0 

6.0 

0% 

2.0 

40.0  0.05556 

0.7 

Match  Against  CommAir  Profile 

182 

0.00028  0.05056 

2.0 

4.0 

95% 

40.0 

7280.0  0.05056 

144.0 

Match  Against  Intel  Information 

10 

0.00278  0.02778 

10.0 

9.0 

0% 

10.0 

100.0  0.02778 

3.6 

Examine  Kinematic  Data 

105 

0.00139  0.14583 

4.0 

7.0 

50% 

8.0 

840.0  0.14583 

5.8 

Obtain  Visual  D 

5 

0.00278  0.01389 

2.0 

1.0 

0% 

2.0 

10.0  0.01389 

0.7 

Conduct  Verbal  Query 

9 

0.00278  0.02500 

2.0 

2.0 

0% 

2.0 

18.0  0.02500 

0.7 

Correl  = 

0.80 

37732.0  0.43722 

86.3 

RELAY 

Send  Over  Links 

64 

0.00083  0.05333 

2.0 

1.0 

80% 

10.0 

640.0  0.05333 

12.0 

Discuss  Picture  with  Battle  Force  Units 

64 

0.00278  0.17778 

4.0 

2.0 

0% 

4.0 

256.0  0.17778 

1.4 

0.99361 

Correl » 

1.00 

896.0  0.23111 

3.9 

Table  17.  “As  Is”  SSDS  IDS  KVA  Analysis 

F.  “TO  BE”  KVA  ANALYSIS 

The  “To  Be”  analysis  is  a  notional  representation  of  the  possible  effects  given  a 
futuristic  scenario  that  incorporates  changes  to  the  sub  processes.  For  the  purposes  of 
this  analysis,  sub  processes  that  could  possibly  be  affected  through  the  use  of  an  open 
architectural  framework  have  been  adjusted  to  reflect  the  changes.  Only  those  processes 
that  could  be  affected  will  be  provided  in  this  section.  Sub  processes  that  would  not  be 
affected  through  the  application  of  an  open  architecture  are  not  presented  in  this  section, 
and  should  be  considered  to  remain  unchanged. 

1,  Open  Architecture  Reengineering 

Through  an  analysis  of  the  “As  Is”  processes,  it  was  determined  that  the  optimal 
enhancements  to  an  operational  environment  could  be  achieved  in  the  areas  of  systems 
integration  and  hardware  scalability  through  the  application  of  open  architecture.  The 
analysis  was  focused  through  the  ROK  results,  but  was  not  limited  to  only  using  ROK  as 
a  determining  factor.  The  ROK  results  led  to  more  pointed  questions: 


•  Why  were  the  “Obtain  Link  Information”  and  “Verify  IFF  Signal” 
ROK’s  orders  of  magnitude  greater  than  the  other  processes? 

•  Why  was  there  a  difference  in  some  process  ROK’s  between  watch 
stations  across  the  platforms? 

•  Should  all  watch  stations  be  trained  for  each  of  the  sub  processes? 
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Taking  this  idea  and  reengineering  the  proeesses  involving  these  areas  provided 
inereases  in  the  ROK  for  each  sub  process.  For  the  purposes  of  this  research,  the  effect 
of  training  time  through  open  architecture  could  not  be  determined,  so  the  category  was 
left  unchanged.  Assumptions  for  the  reengineering  methodology  were:  1)  integration 
through  the  use  of  middleware  was  necessary  until  Category  3  OACE  level  could  be 
reached  for  systems  being  evaluated  and  2)  hardware  would  be  Commercial-Off- The- 
Shelf  (COTS)  equipment. 

2,  “To  Be”  Process  Data 

In  presenting  the  following  scenarios  it  was  necessary  to  estimate  the  changes  in 
“AWT”  and  “%IT”  categories  due  to  the  fact  that  the  “To  Be”  analysis  is  an  estimation. 
For  all  scenarios  it  was  assumed  that  a  transformation  to  open  architecture  would 
automate  a  sub  process  to  the  extent  that  the  “%IT”  category  would  be  95%.  Automation 
in  these  sub  processes  would  result  in  a  decrease  in  “AWT”  as  it  would  no  longer  be 
necessary  for  a  watch  stander  to  be  involved  in  the  conduct  of  the  sub  process,  so  the  time 
needed  to  complete  the  action  would  be  reduced. 

The  sub  processes  affected  were  “Update  GCCS-M”,  “Verify  EW  Emissions”, 
“Verily  Point  of  Origin”  and  “Match  against  ATO”.  Each  of  the  watch  stations  was 
affected,  though  some  more  than  others  as  not  all  sub  processes  were  applicable  to  all 
watch  stations.  Tables  19  through  30  represent  the  analysis  of  each  watch  station  after  a 
notional  reengineering  of  the  sub  processes  occurs. 

The  “Update  GCCS-M”  sub  process  could  be  affected  through  an  application  of  a 
middle  ware  product  until  the  AEGIS  and  SSDS  platforms  could  reach  a  Category  3 
OACE  level.  The  current  version  of  GCCS-M  provides  an  “open-system  commercial  and 
government  standards-based  architecture  that  maximizes  use  of  non-developmental  items 
and  is  in  compliance  with  the  Global  Information  Grid-Enterprise  Services  to  ensure 
interoperability  with  U.S.  Joint  and  other  naval  C4I  systems”  (Globalsecurity.org).  Due 
to  its  use  of  OA  it  was  determined  to  be  a  candidate  for  incorporation  into  an  AEGIS  or 
SSDS  platform  that  conformed  to  open  architecture  standards.  While  some  critical 
interfaces  have  yet  to  be  tested,  it  would  be  a  means  to  enhance  the  operational  value  of 
the  systems  through  a  reduction  in  time,  manpower  and  possible  training  required  to 
conduct  the  process. 
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“Verify  EW  Emissions”  is  hindered  through  hardware  limitations  due  to  the 
proprietary  nature  of  the  equipment.  Applying  an  open  architecture  framework  to  the 
EW  systems  would  facilitate  a  COTS  based  environment  that  could  easily  be  upgraded  to 
accommodate  greater  processor  speeds.  The  ability  to  communicate  the  data  from  the 
EW  systems  electronically  to  the  CIC  personnel  that  require  it  would  greatly  enhance  the 
efficiency  of  the  CIC  through  more  timely  situational  awareness.  Operators  would  be 
freed  up  to  conduct  other  tasks  that  they  would  otherwise  not  have  time  to  accomplish. 

“Verily  Point  of  Origin”  sub  process  could  be  enhanced  through  better  integration 
of  sensors  within  the  AEGIS  and  SSDS  platforms.  An  open  architecture  framework 
could  enable  greater  sensor  and  data  integration  which  would  provide  more  enhanced 
correlation  to  pinpoint  the  point  of  origin  of  an  aircraft  or  ship.  Point  of  origin  for 
friendly  force  contacts  could  be  queried  from  an  open  GCCS-M  system  and  ATO,  while 
neutral  force  contacts  could  be  interrogated  from  host  nation  airports,  assuming  data 
formats  were  standardized  and  provided  by  host  nations.  Presenting  an  open  architecture 
framework  to  the  AEGIS  and  SSDS  platforms  could  facilitate  interfaces  to  these  other 
systems  in  order  to  provide  an  automated  query  for  point  of  origin.  The  automation  of 
this  sub  process  would  free  up  watch  standers  to  accomplish  other  tasks,  while  at  the 
same  time  providing  quicker  data  flow. 

Easily,  the  sub  process  “Match  Against  ATO”  could  be  greatly  enhanced  through 
an  open  architecture  framework.  Current  initiatives  are  being  looked  into  for  feasibility 
of  integrating  the  ATO  into  surface  combat  ships  though  an  automatic  parsing  and 
feeding  of  messages  into  ID  engines  on  AEGIS  and  SSDS  platforms.  Using  LINK  1 1  or 
LINK  16,  data  could  be  fed  into  the  systems.  Through  an  application  of  middleware  and 
COTS  hardware,  the  information  provided  in  the  ATO  could  be  integrated  into  the 
AEGIS  and  SSDS  platforms,  greatly  reducing  the  manpower  required  to  accomplish  this 
sub  process. 

a.  AEGIS  Tactical  Action  Officer  Analysis 

Table  18  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  a  TAO  aboard  an  AEGIS  platform  after  reengineering  with  an 
open  architecture  approach. 
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Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  AWT 
per  Hour  (Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Tactical  Action  Officer  (TAO) 

TRACK 

Uodate  GCCS-M 

2  0.00028 

0.00056 

6.0 

1.0 

95% 

120.0 

240.0 

0.0 

432.0 

IDENTIFY 

Verify  EW  err^ions 

25  0.00028 

0.00694 

18.0 

5.0 

95% 

360.0 

9000.0 

0.0 

1296.0 

Verify  Point  of  Origin 

12  0.00028 

0.00333 

6.0 

3.0 

95% 

120.0 

1440.0 

0.0 

432.0 

Match  Against  ATO 

20  0.00028 

0.00556 

6.0 

6.0 

95% 

120.0 

2400.0 

0.0 

432.0 

Table  18.  “To  Be”  AEGIS  TAG  KVA  Analysis 


b.  SSDS  Tactical  Action  Officer  Analysis 

Table  19  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  a  TAG  aboard  an  SSDS  platform  after  reengineering  with  an 
open  architecture  approach. 


Billet 

Number  of 

Contact  ID  Subprocess  Personnel 

Actions  per 
Hour 

AWT 

(Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Tactical  Action  Officer  (TAO) 

TRACK 

Update  GCCS-M 

1  2 

0.00028 

0.00056 

2.0 

1.0 

95% 

40.0 

80.0 

0.0 

144.0 

IDENTIFY 

Verify  EW  emissions 

25 

0.00028 

0.00694 

6.0 

5.0 

95% 

120.0 

3000.0 

0.0 

432.0 

Verify  Point  of  Origin 

12 

0.00028 

0.00333 

2.0 

3.0 

95% 

40.0 

480.0 

0.0 

144.0 

Match  Aoanst  ATO 

1  20 

0.00028 

0.00556 

2.0 

6.0 

95% 

40.0 

800.0 

0.0 

144.0 

Table  19.  “To  Be”  SSDS  TAG  KVA  Analysis 


c.  AEGIS  Anti-Air  Warfare  Coordinator 

Table  20  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  an  AAWC  aboard  an  AEGIS  platform  after  reengineering  with 
an  open  architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of  Actions  AWT 
Personnel  per  Hour  (Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

TLT 

NLT  ITS  (Hours) 

NUM  DEN 

ROK 

Anti  Air  Warfare  Coordinator  (AAWC) 

IDENTIFY 

Verify  EW  emissions 

1  25  0.00028 

0.00694 

18.0 

5.0  95%  360.0 

9000.0  0.0 

1296.0 

Verify  Point  of  Origin 

1  12  0.00028 

0.00333 

6.0 

3.0  95%  120.0 

1440.0  0.0 

432.0 

Match  Against  ATO 

1  20  0.00028 

0.00556 

6.0 

6.0  95%  120.0 

2400.0  0.0 

432  0 

Table  20.  “To  Be”  AEGIS  AAWC  KVA  Analysis 


d.  SSDS  Anti-Air  Warfare  Coordinator 

Table  21  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  an  AAWC  aboard  an  SSDS  platform  after  reengineering  with  an 
open  architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of 

Personnel 

Actions  per 
Hour 

AWT 

(Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Anti  Air  Warfare  Coordinator  (AAWC) 

IDENTIFY 

Verify  EW  emissions 

25 

0.00028 

0.00694 

6.0 

5.0 

95% 

120.0 

3000.0 

0.0 

432.0 

Verify  Point  of  Origin 

12 

0.00028 

0.00333 

2.0 

3.0 

95% 

40.0 

480.0 

0.0 

144.0 

Match  Against  ATO 

20 

0.00023 

0.00556 

2.0 

6.0 

95% 

40.0 

800.0 

0.0 

144.0 

Table  2 1 .  “To  Be”  SSDS  AAWC  KVA  Analysis 
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e.  AEGIS  Surface  Warfare  Coordinator 

Table  22  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  an  SUWC  aboard  an  AEGIS  platform  after  reengineering  with  an 
open  architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of  Actions 
Personnel  per  Hour 

AWT 

(Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT  ITS 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Surface  Warfare  Coordinator  (SUWC) 

TRACK 

Update  GCCS-M 

1  20 

0.00028 

0.00556 

6.0 

1.0  95% 

120.0 

2400.0 

0.0 

432.0 

IDENTIFY 

Verify  EW  emissions 

1  15 

0.00028 

0.00417 

18.0 

4.0  95% 

360.0 

5400.0 

0.0 

1296.0 

Verify  Point  ofOrioin 

1  1 

0.00028 

0.00028 

6.0 

3.0  95% 

120.0 

120.0 

0.0 

432.0 

Table  22.  “To  Be”  AEGIS  SUWC  KVA  Analysis 


f  SSDS  Surface  Warfare  Coordinator 

Table  23  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  an  SUWC  aboard  an  SSDS  platform  after  reengineering  with  an 
open  architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of  Actions  per 
Personnel  Hour 

AWT 

(Hours) 

Total  Work 
Time  p>erHr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM 

DEN  ROK 

Surface  Warfare  Coordinator  (SUWC) 

TRACK 

Update  GCCS-M 

1  20 

0.00028 

0.00556 

2.0 

1.0 

95% 

40.0 

800.0 

0.0  144.0 

IDENTIFY 

Verify  EW  emissions 

1  15 

0.00028 

0.00417 

6.0 

4.0 

95% 

120.0 

1800.0 

0.0  432.0 

Verify  Point  of  Onom 

1  1 

0.00028 

0.00028 

2.0 

3.0 

95% 

40.0 

40.0 

0.0  144.0 

Table  23.  “To  Be”  SSDS  SUWC  KVA  Analysis 
g.  AEGIS  Combat  Systems  Coordinator 

Table  24  depicts  the  notional  track  management  core  processes  involved 


in  the  KVA  analysis  for  a  CSC  aboard  an  AEGIS  platform  after  reengineering  with  an 
open  architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of 

Personnel 

Actions 
per  Hour 

AWT  Total  Work 
(Hours)  Time  per  Hr 

ALT 

(Hours) 

NLT 

ITS 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Combat  Systems  Coordinator  (CSC) 

IDENTIFY 

Verify  EW  emissions 

25 

0.00028 

0.00694 

5.0 

3.0 

95% 

100.0 

2500.0 

0.0 

360.0 

Verify  Point  of  Origin 

1 

0.00028 

0.00028 

2.0 

1.0 

95% 

40.0 

40.0 

0.0 

144.0 

Match  Aoainst  ATO 

2 

0.00028 

0.00056 

2.0 

4.0 

95% 

40.0 

80.0 

0.0 

144,0 

Table  24.  “To  Be”  AEGIS  CSC  KVA  Analysis 


h.  SSDS  Combat  Systems  Coordinator 

Table  25  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  a  CSC  aboard  an  SSDS  platform  after  reengineering  with  an 
open  architecture  approach. 
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Billet 

Contact  ID  Subprocess 

Number  of  Actions  per  AWT 
Personnel  Hour  (Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT 

IT% 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Combat  Systems  Coordinator  (CSC) 

IDENTIFY 

Verify  EW  emissions 

1  25  0.00028 

0.00694 

6.0 

3.0 

95% 

120.0 

3000.0 

0.0 

432.0 

Verify  Point  of  Origin 

1  1  0.00028 

0.00028 

2.0 

1.0 

95% 

40.0 

40.0 

0.0 

144.0 

Match  AoainstATO 

1  2  0.00028 

0.00056 

2.0 

4.0 

95% 

40.0 

80.0 

0.0 

144.0 

Table  25.  “To  Be”  SSDS  CSC  KVA  Analysis 


L  AEGIS  Tactical  Information  Coordinator 

Table  26  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  a  TIC  aboard  an  AEGIS  platform  after  reengineering  with  an 
open  architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of  Actions  AWT 
Personnel  per  Hour  (Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

TLT 

NLT  IT%  (Hours) 

NUM 

DEN 

ROK 

Tactical  Information  Coordinator  (TIC) 

IDENTIFY 

Verify  EW  emissions 

1  25 

0.00028 

0.00694 

6.0 

5.0  95%  120.0 

3000.0 

0.0 

432.0 

Verify  Point  of  Origin 

1  12 

0.00028 

0.00333 

2.0 

3.0  95%  40.0 

480.0 

0.0 

144.0 

Match  AoainstATO 

1  20 

0.00028 

0.00556 

2.0 

6.0  95%  40.0 

800.0 

0.0 

144.0 

Table  26.  “To  Be”  AEGIS  TIC  KVA  Analysis 


j.  SSDS  Tactical  Information  Coordinator 

Table  27  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  a  TIC  aboard  an  SSDS  platform  after  reengineering  with  an  open 
architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of  Actions  per 
Personnel  Hour 

AWT  Total  Work 
(Hours)  Time  per  Hr 

ALT 

(Hours) 

NLT  IT% 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Tactical  Information  Coordinator  (TIC) 

IDENTIFY 

Verify  EW  emissions 

1  25 

0.00028 

0.00694 

6.0 

5.0  95% 

120.0 

3000.0 

0.0 

432.0 

Verify  Point  of  Origin 

1  12 

0.00028 

0.00333 

2.0 

3.0  95% 

40.0 

480.0 

0.0 

144.0 

Match  AaainstATO 

1  20 

0.00028 

0.00556 

2.0 

6.0  95% 

40.0 

800.0 

0.0 

144.0 

Table  27.  “To  Be”  SSDS  TIC  KVA  Analysis 


k.  AEGIS  Identification  Supervisor 

Table  28  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  an  IDS  aboard  an  AEGIS  platform  after  reengineering  with  an 
open  architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of  Actions  AWT 
Persrmnel  per  Hour  (Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

TLT 

NLT  IT%  (Hours) 

NUM 

DEN 

ROK 

Identification  Supervisor  (DS) 

IDENTIFY 

Verify  EW  emissions 

1  25  0.00028 

0.00694 

6.0 

5.0  95%  120.0 

3000.0 

0.0 

432.0 

Verify  Point  of  Origin 

1  12  0.00028 

0.00333 

2.0 

3.0  95%  40.0 

480.0 

0.0 

144.0 

Match  AoainstATO 

1  20  0.00028 

0.00556 

2.0 

6.0  95%  40.0 

800.0 

0.0 

144.0 

Table  28.  “To  Be”  AEGIS  IDS  KVA  Analysis 
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1.  SSDS  Identification  Supervisor 

Table  29  depicts  the  notional  track  management  core  processes  involved 
in  the  KVA  analysis  for  an  IDS  aboard  an  SSDS  platform  after  reengineering  with  an 
open  architecture  approach. 


Billet 

Contact  ID  Subprocess 

Number  of  Actions  per 
Personnel  Hour 

AWT 

(Hours) 

Total  Work 
Time  per  Hr 

ALT 

(Hours) 

NLT 

IT% 

TLT 

(Hours) 

NUM 

DEN 

ROK 

Identihcation  Supervisor  (DS) 

IDENTIFY 

Verify  EW  emissions 

1  25 

0.00028 

0.00694 

6.0 

5.0 

95% 

120.0 

3000.0 

0.01 

432,0 

Verify  Point  of  Origin 

1  12 

0.00028 

0.00333 

2.0 

3.0 

95% 

40.0 

460.0 

0.00 

144.0 

Match  Aoanst  ATO 

1  20 

0.00028 

0.005E6 

2.0 

6.0 

95% 

40.0 

300.0 

0.01 

144.0 

Table  29.  “To  Be”  SSDS  IDS  KVA  Analysis 

G.  WATCH  STATION  COMPARATIVE  ANALYSIS 

Now  that  both  the  “As  Is”  and  “To  Be”  data  have  been  presented,  it  is  important 
to  present  the  results  in  a  side-by-side  comparison.  Each  of  the  watch  stations  are 
presented,  with  %  of  change  in  ROK  bolded.  The  “Correlate”  and  “Relay”  processes 
were  determined  not  to  have  any  additional  value  added  through  an  open  architecture 
approach  at  this  time.  Each  watch  station  saw  an  increased  ROK  in  the  “Identify” 
process,  and  two  had  increases  in  the  “Track”  process  as  well.  Through  an  insertion  of 
automation  founded  on  an  OA  approach,  and  reduced  “AWT”,  it  was  apparent  that  OA 
could  be  used  to  increase  the  operational  value  of  a  situational  awareness  system. 


Tactical  Action  Officer 

AEGIS  "As  Is"  ROK 

AEGIS  "To  Be"  ROK 

%  Change 

SSDS  "As  Is"  ROK 

SSDS  "To  Be"  ROK 

% 

Change 

CORRELATE 

416.43 

416.43 

0.00 

138.81 

138.81 

0.00 

Obtain  Link  Information 

1728.00 

1728.00 

0.00 

576.00 

576.00 

0.00 

Identify  "Same  Contact.  Multiple  Track" 

15.43 

15.43 

0.00 

5.14 

5.14 

0.00 

Verify  OtherTrack  Sources 

19.29 

19.29 

0.00 

6.43 

6.43 

0.00 

TRACK 

6.93 

10.21 

47.42 

2.31 

3.40 

47.42 

Monitor  Suspect  Tracks 

7.71 

7.71 

0.00 

2.57 

2.57 

0.00 

Update  Tracks 

4.41 

4.41 

0.00 

1.47 

1.47 

0.00 

Update  GCCS-M 

10.80 

432.00 

3900.00 

3.60 

144.00 

3900.00 

IDENTIFY 

216.60 

395.97 

82.81 

72.20 

130.29 

80.45 

Verify  FF  signal 

1728.00 

1728.00 

0.00 

576.00 

576.00 

0.00 

Verify  EW  emissions 

25.92 

1296.00 

4900.00 

8.64 

432.00 

4900.00 

Verify  Point  of  Origki 

2.16 

432.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  ATO 

2.16 

432.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  CommAir  Profile 

432.00 

432.00 

0.00 

144.00 

144.00 

0.00 

Match  Against  Intel  Information 

10.80 

10.80 

0.00 

3.60 

3.60 

0.00 

Examine  Kinematic  Data 

17.28 

17.28 

0.00 

5.76 

5.76 

0.00 

Obtain  Visual  D 

2.16 

2.16 

0.00 

0.72 

0.72 

0.00 

Conduct  Verbal  Query 

2.16 

2.16 

0.00 

0.72 

0.72 

0.00 

RELAY 

7.20 

7.20 

0.00 

2.40 

2.40 

0.00 

Send  Over  Links 

36.00 

36.00 

0.00 

12.00 

12.00 

0.00 

Discuss  Picture  with  Battle  Force  Units 

4.32 

4.32 

0.00 

1.44 

1.44 

0.00 

Table  30.  TAO  Einal  Results 
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Anti  Air  Warfare  Coordinator 

AEGIS  "As  Is"  ROK 

AEGIS  "To  Be"  ROK 

%  Change 

SSDS"As  Is"  ROK 

SSDS"To  Be"  ROK 

% 

Change 

CORRELATE 

416.43 

416.43 

0.00 

138.81 

138.81 

0.00 

Obtain  Link  Information 

1728.00 

1728.00 

0.00 

576.00 

576.00 

0.00 

Identify  "San«  Contact.  Multiple  Track" 

15.43 

15.43 

0.00 

5.14 

5.14 

0.00 

Verify  Other  Track  Sources 

19.29 

19.29 

0.00 

6.43 

6.43 

0.00 

TRACK 

5.91 

5.91 

0.00 

1.97 

1.97 

0.00 

Monitor  Suspect  Tracks 

7.71 

7.71 

0.00 

2.57 

2.57 

0.00 

Update  Tracks 

4.41 

4.41 

0.00 

1.47 

1.47 

0.00 

IDENTIFY 

214.57 

346.30 

61.40 

71.52 

115.43 

61.40 

Verify  IFF  signal 

1728.00 

1728.00 

0.00 

576.00 

576.00 

0.00 

Verify  EW  emissions 

25.92 

1296.00 

4900.00 

8.64 

432.00 

4900.00 

Verify  Point  of  Origin 

2.16 

432.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  ATO 

2.16 

432.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  CommAir  Profile 

432.00 

432.00 

0.00 

144.00 

144.00 

0.00 

Match  Against  Intel  Information 

10.80 

10.80 

0.00 

3.60 

3.60 

0.00 

Examine  Kinematic  Data 

17.28 

17.28 

0.00 

5.76 

5.76 

0.00 

Obtain  Visual  D 

2.16 

2.16 

0.00 

0.72 

0.72 

0.00 

Conduct  Verbal  Query 

2.16 

2.16 

0.00 

0.72 

0.72 

0.00 

RELAY 

5.24 

5.24 

0.00 

1.75 

1.75 

0.00 

Send  Oyer  Links 

36.00 

36.00 

0.00 

12.00 

12.00 

0.00 

Discuss  Picture  with  Battle  Force  Unit* 

4.32 

4.32 

0.00 

1.44 

1.44 

0.00 

Table  3 1 .  AAWC  Final  Results 


Surface  Warfare  Coordinator 

AEGIS  "As  Is"  ROK 

AEGIS  "To  Be"  ROK 

%  Change 
0.00 

SSDS  "As  Is"  ROK 

SSDS  "To  Be"  ROK 

% 

Change 

CORRELATE 

520.68 

520.68 

173.56 

173.56 

0.00 

Obtain  Link  Information 

1728.00 

1728.00 

0.00 

576.00 

576.00 

0.00 

Identify  "Same  Contact.  Multiple  Track" 

15.43 

15.43 

0.00 

5.14 

5.14 

0.00 

Verify  Other  Track  Sources 

19.29 

19.29 

0.00 

6.43 

6.43 

0.00 

TRACK 

8.15 

92.81 

1038.76 

2.72 

30.9 

1038.76 

Monitor  Suspect  Tracks 

7.71 

7.71 

0.00 

2.57 

2.57 

0.00 

Update  Tracks 

4.41 

4.41 

0.00 

1.47 

1.47 

0.00 

Update  GCCS-M 

10.80 

432.00 

3900.00 

3.60 

144.00 

3900.00 

IDENTIFY 

31.12 

68.82 

121.11 

10.37 

22.94 

121.11 

Verify  FF  signal 

1728.00 

1728.00 

0.00 

576.00 

576.00 

0.00 

Verify  EW  emissions 

25.92 

1296.00 

4900.00 

8.64 

432.00 

4900.00 

Verify  Point  of  Origin 

2.16 

432.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  Intel  Inforn^tion 

10.80 

10.80 

0.00 

3.60 

3.60 

0.00 

Examine  Kinematic  Data 

17.28 

17.28 

0.00 

5.76 

5.76 

0.00 

Obtain  Visual  D 

2.16 

2.16 

0.00 

0.72 

0.72 

0.00 

Conduct  Verbal  Query 

2.16 

2.16 

0.00 

0.72 

0.72 

0.00 

RELAY 

6.11 

6.11 

0.00 

2.04 

2.04 

0.00 

Send  Oyer  Links 

36.00 

36.00 

0.00 

12.00 

12.00 

0.00 

Discuss  Picture  with  Battle  Force  Units 

4.32 

4.32 

0.00 

1.44 

1.44 

0.00 

Table  32.  SUWC  Final  Results 


Combat  Systems  Coordinator 

AEGIS  "As  Is"  ROK 

AEGIS  "To  Be"  ROK 

%  Change 

SSDS  "As  Is"  ROK 

SSDS  "To  Be"  ROK 

% 

Change 

CORRELATE 

104.19 

104.19 

0.00 

138.81 

138.81 

0.00 

Obtain  Link  Information 

432.00 

432.00 

0.00 

576.00 

576.00 

0.00 

Identify  'Same  Contact.  Multiple  Track* 

3.86 

3.86 

0.00 

5.14 

5.14 

0.00 

Verify  Other  Track  Sources 

5.14 

5.14 

0.00 

6.43 

6.43 

0.00 

TRACK 

1.80 

1.80 

0.00 

2.26 

2.26 

0.00 

Monitor  Suspect  Tracks 

1.93 

1.93 

0.00 

2.57 

2.57 

0.00 

Uodate  Tracks 

1.47 

1.47 

0.00 

1.47 

1.47 

0.00 

IDENTIFY 

32.80 

51.84 

58.02 

34.85 

56.70 

62.72 

Verify  FF  signal 

432.00 

432.00 

0.00 

576.00 

576.00 

0.00 

Verify  EW  emissions 

7.20 

360.00 

4900.00 

8.64 

432.00 

4900.00 

Verify  Point  of  Origin 

0.72 

144.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  ATO 

0.72 

144.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  CommAir  Profile 

144.00 

144.00 

0.00 

144.00 

144.00 

0.00 

Match  Against  Intel  Information 

3.60 

3.60 

0.00 

3.60 

3.60 

0.00 

Examine  Kinematic  Data 

5.76 

5.76 

0.00 

5.76 

5.76 

0.00 

RELAY 

12.00 

12.00 

0.00 

12.00 

12.00 

0.00 

Send  Oyer  Links 

12.00 

12.00 

0.00 

12.00 

12.00 

0.00 

Table  33.  CSC  Final  Results 
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Tactical  Informaiton  Coordinator 

AEGIS  "As  Is"  ROK 

AEGIS  "To  Be"  ROK 

%  Change 

SSDS"As  Is"  ROK 

SSDS  "To  Be"  ROK 

% 

Change 

CORRELATE 

138.81 

138.81 

0.00 

138.81 

138.81 

0.00 

Obtain  Link  Information 

576.00 

576.00 

0.00 

576.00 

576.00 

0.00 

Identify  "Same  Contact.  Multiple  Track" 

5.14 

5.14 

0.00 

5.14 

5.14 

0.00 

Verify  Other  Track  Sources 

6.43 

6.43 

0.00 

6.43 

6.43 

0.00 

TRACK 

1.78 

1.78 

0.00 

1.78 

1.78 

0.00 

Monitor  Suspect  Tracks 

2.57 

2.57 

0.00 

2.57 

2.57 

0.00 

UodateTracks 

1.47 

1.47 

0.00 

1.47 

1.47 

0.00 

IDENTIFY 

80.18 

114.67 

43.01 

80,18 

114.67 

43.01 

Verify  IFF  signal 

576.00 

576.00 

0.00 

576.00 

576.00 

0.00 

Verify  EW  emissions 

8.64 

432.00 

4900.00 

8.64 

432.00 

4900.00 

Verify  Point  of  Origin 

0.72 

144.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  ATO 

0.72 

144.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  CommAir  Profile 

144.00 

144.00 

0.00 

144.00 

144.00 

0.00 

Match  Against  Intel  Information 

3.60 

3.60 

0.00 

3.60 

3.60 

0.00 

Examine  Kinematic  Data 

5.76 

5.76 

0.00 

5.76 

5.76 

0.00 

Obtain  Visual  D 

0.72 

0.72 

0.00 

0.72 

0.72 

0.00 

Conduct  Verbal  Query 

0.72 

0.72 

0.00 

0.72 

0.72 

0.00 

RELAY 

2.04 

2.04 

0.00 

2.04 

2.04 

0.00 

Send  Over  Links 

12.00 

12.00 

0.00 

12.00 

12.00 

0.00 

Discuss  Picture  with  Battle  Force  Unit* 

1.44 

1.44 

0.00 

1.44 

1.44 

0.00 

Table  34.  TIC  Final  Results 


Identification  Supervisor 

AEGIS  "As  Is"  ROK 

AEGIS  *To  Be"  ROK 

%  Change 

SSDS  "As  Is"  ROK 

SSDS  "To  Be"  ROK 

%  Change 

CORRELATE 

138.81 

138.81 

0.00 

138,81 

138.81 

0.00 

Obtain  Link  Information 

576.00 

576.00 

0.00 

576.00 

576.00 

0.00 

Identify  "Same  Contact.  Multiple  Track" 

5.14 

5.14 

0.00 

5.14 

5.14 

0.00 

Verify  Other  Track  Sources 

6.43 

6.43 

0.00 

6.43 

6.43 

0.00 

TRACK 

1.78 

1.78 

0.00 

1.78 

1.78 

0.00 

Monitor  Suspect  Tracks 

2.57 

2.57 

0.00 

2.57 

2.57 

0.00 

UodateTracks 

1.47 

1.47 

0.00 

1.47 

1.47 

0.00 

IDENTIFY 

86.30 

126.42 

46.49 

86.30 

126.42 

46,49 

Verify  IFF  signal 

576.00 

576.00 

0.00 

576.00 

576.00 

0.00 

Verify  EW  emissions 

8.64 

432.00 

4900.00 

8.64 

432.00 

4900.00 

Verify  Point  of  Origin 

0.72 

144.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  ATO 

0.72 

144.00 

19900.00 

0.72 

144.00 

19900.00 

Match  Against  ConvnAir  Profile 

144.00 

144.00 

0.00 

144.00 

144.00 

0.00 

Match  Against  Intel  Information 

3.60 

3.60 

0.00 

3.60 

3.60 

0.00 

Examine  Kinematic  Data 

5.76 

5.76 

0.00 

5.76 

5.76 

0.00 

Obtain  Visual  D 

0.72 

0.72 

0.00 

0.72 

0.72 

0.00 

Conduct  Verbal  Query 

0.72 

0.72 

0.00 

0.72 

0.72 

0.00 

RELAY 

3.88 

3.88 

0.00 

3.88 

3.88 

0.00 

Send  Over  Links 

12.00 

12.00 

0.00 

12.00 

12.00 

0.00 

Discuss  Picture  with  Battle  Force  Units 

1.44 

1.44 

0.00 

1.44 

1.44 

0.00 

Table  35.  IDS  Final  Results 

H.  FINAL  ROK  RESULTS 

When  combining  the  ROK  for  each  watch  station  we  can  generate  a  complete 
picture  of  the  return  on  knowledge  capital  invested  for  each  process  in  both  the  “As  Is” 
and  “To  Be”  scenarios.  This  representation  better  exemplifies  the  operational  value  that 
an  OA  framework  can  provide  the  Navy.  Differences  in  process  ROK  results  across  each 
platform  are  attributed  to  the  difference  in  the  amount  of  knowledge  required  for  each  of 
the  platforms. 


57 


"AS  IS"  Processes 

AEGIS  ROK 

SSDS  ROK 

Correlate 

1735.35 

867.61 

Track 

26,34 

12.81 

Identify 

661.58 

355.43 

Relay 

36.47 

24  10 

Table  36.  “As  Is”  ROK  Totals 


■TO  BE"  Processei 

AEGIS  ROK 

SSDS  ROK 

Correlate 

1735.35 

867.61 

Track 

114.29 

42.13 

Identify 

1104.02 

566.45 

Relay 

36.47 

24.10 

Table  37.  “To  Be”  ROK  Totals 


Difference 

AEGIS  ROK 

SSDS  ROK 

Correlate 

0.00 

0.00 

Track 

87.96 

29.32 

Identify 

442.44 

211.02 

Relay 

0.00 

0.00 

Table  38.  ROK  Change 


Table  38  depicts  the  dramatic  effects  that  an  OA  approach  can  have  on  the 
“Track”  and  “Identify”  processes.  The  ROK  indicated  that  after  applying  an  OA 
approach  efficiency  with  which  knowledge  assets  are  used  within  these  processes 
dramatically  increased. 

Knowledge  is  a  key  component  in  the  efficient  accomplishment  of  any  mission, 
and  therefore  provides  value  to  an  operational  environment.  The  Department  of  the 
Navy,  Chief  Information  Officers’  (DON  CIO)  Information  Management/Information 
Technology  (IM/IT)  Strategic  Plans’  stated  goal  to  “build  a  knowledge  sharing  culture 
and  exploit  new  IT  tools  to  facilitate  knowledge  transfer  across  the  globally  distributed 
enterprise”,  through  “optimizing  the  effective  application  of  intellectual  capital  to  achieve 
organizational  objectives”  (DON  CIO,  2001)  provides  another  impetus  to  use  knowledge 
as  a  surrogate  for  value  in  our  core  processes. 


58 


Increasing  the  performanee  of  knowledge  eapital  assets  within  a  proeess  provides 
inereased  operational  value  and  ean  have  a  signifieant  impact  on  the  conduet  of  naval 
missions. 
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V.  CONCLUSIONS 


Investments  in  information  teehnology  just  for  the  sake  of  information  teehnology 
have  put  the  Navy  in  a  precarious  position.  Incompatibility,  cost  overruns  and  missed 
opportunities  for  the  efficient  use  of  new  technology  are  often  caused  through  antiquated 
government  standards  and  application  of  proprietary  approaches  to  systems  design. 
Leveraging  today’s  technologies  with  an  OA  approach  can  help  the  Navy  realize  the  full 
potential  of  its  systems  and  processes. 

This  thesis  provided  insight  into  the  operational  value  that  can  be  achieved  by  an 
OA  approach  through  an  increase  in  the  performance  of  knowledge  capital  assets,  such  as 
situational  awareness  systems.  Through  an  application  of  KVA,  the  value  of  open 
architecture  can  be  quantified  and  processes  can  be  evaluated  on  a  common  basis. 
Through  application  of  KVA,  deficiencies  and  efficiencies  can  be  seen  and  reengineering 
efforts  can  be  tailored  and  prioritized  to  provide  the  greatest  operational  value  to  the  war 
fighter  by  the  most  efficient  and  effective  use  of  the  OA  approach. 

A.  RESEARCH  QUESTIONS 

The  intent  of  this  thesis  was  to  answer  the  questions  proposed  in  the  first  chapter. 
Through  a  decomposition  of  the  track  management  process  and  subsequent  analysis  using 
the  Knowledge  Value  Added  methodology,  the  specifics  of  the  questions  can  now  be 
addressed. 

1,  Can  Open  Architecture  Improve  the  Operational  Value  in  a 
Situational  Awareness  System? 

The  underlying  foundation  of  OA,  if  applied  correctly,  achieves  attributes 
required  for  increasing  the  operational  value  of  such  systems.  Operational  value  is 
sometimes  lost  in  the  acquisitions  of  systems,  due  in  large  part  to  financial  and  schedule 
limitations  that  must  be  addressed.  While  an  OA  approach  has  been  proven  in  many 
cases  to  improve  the  acquisitions  and  maintenance  cycles,  little  research  is  conducted  on 
the  operational  value  of  the  OA  approach  in  information  technology  to  support  core 
processes.  The  value  of  a  system  to  an  operator  is  one  that  can  decrease  work  time 
(freeing  the  operator  to  conduct  other  functions);  decreased  time  to  learn  the  system 
(again,  freeing  the  operator  to  conduct  other  tasks);  and  increase  the  processing  power 
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while  decreasing  the  processing  time  for  each  action  (providing  increased  capability  and 
efficiency).  This  can,  in  turn,  be  achieved  through  proper  management  of  knowledge 
assets  within  an  organization’s  core  processes. 

Hardware  that  is  consistent  with  the  latest  technological  industry  standards 
provides  the  greatest  processing  power  with  the  least  amount  of  latency.  Maintaining  the 
ability  to  upgrade  hardware  when  technology  outpaces  current  systems,  without  a 
complete  replacement  of  the  system,  provides  the  operator  the  greatest  capability,  thereby 
creating  value.  In  an  environment  that  is  not  built  on  an  OA  foundation,  hardware 
reaches  its  capacity  and  functionality  limitations  and  cannot  increase  its  capability 
through  the  leveraging  of  advanced  technology.  Using  COTS  equipment,  an  OA 
approach  can  keep  pace  with  technology  and  thus  can  maintain  the  decisive  advantage 
the  Navy  has  come  to  expect. 

Insertion  of  effective  and  efficient  IT  into  core  processes  within  a  situational 
awareness  process  increases  the  operational  value  through  a  decrease  in  work  time  for  the 
operator.  While  proprietary  systems  can  provide  the  IT  resources  that  will  lessen  the 
work  load  on  the  operator,  they  are  not  flexible  enough  to  integrate  with  new 
technologies  as  they  become  available.  An  OA  approach  will  facilitate  seamless 
integration  and  can  thus  continue  to  decrease  the  work  time  for  an  operator  when  new 
technology  becomes  available.  The  value  is  created  through  the  continuous  insertion  of 
IT  assets  so  that  capacity  limits  in  processing  power  are  not  expected. 

Lastly,  the  interoperability  that  is  provided  through  open  architecture  facilitates 
faster,  more  effective  transfer  of  information  between  sensors  and  users.  Integration  of 
multiple  sensors  and  data  resources  provides  operators  greater  knowledge  that  will 
increase  their  situational  awareness.  As  IT  systems  are  integrated  into  core  processes,  the 
value  of  the  processes  increases  through  more  efficient  use  of  resources. 

2.  Can  KVA  be  Applied  to  Current  Track  Management  Systems? 

One  of  the  concepts  put  forth  by  the  DON  CIO  IM/IT  Strategy  is  that  “tacit 
knowledge  is  an  example  of  an  intellectual  asset  whose  value  is  only  realized  when  it  is 
actually  shared  and  reused  effectively”,  and  that  “an  organization’s  ability  to  innovate. 
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improve,  and  learn  ties  direetly  to  that  organization's  value”  (DON  CIO,  2001).  A  means 
to  measure  this  eoneept  will  be  fundamental  in  order  to  achieve  organizational  goals  and 
missions  in  the  Navy. 

A  measurement  of  value  for  IT  systems  and  core  processes  is  extremely  difficult 
to  obtain  for  non-revenue  generating  organizations.  In  such  organizations,  cost  savings 
may  be  an  important  factor,  but  the  true  value  of  a  system  should  be  measured  through  its 
ability  to  produce  outputs.  KVA  can  be  a  valuable  tool  for  assessing  the  value  of  current 
and  future  track  management  systems.  The  measurement  of  embedded,  or  tacit, 
knowledge  in  core  processes  is  extremely  useful  when  comparing  systems.  Systems  that 
are  of  equal  capabilities,  but  require  differing  amounts  of  training  time  and  work  time  can 
be  analyzed  and  evaluated  based  on  common  units  of  output  when  using  the  KVA 
methodology.  Each  of  the  core  processes  can  be  decomposed  and  analyzed  as  to  how 
well  they  provide  a  return  on  knowledge.  Managers  are  not  tied  to  financial  metrics,  but 
rather  can  justify  systems  and  processes  through  a  quantification  of  how  productively  a 
system  or  process  uses  its  embedded  knowledge. 

This  methodology  is  robust  and  defensible  and  provides  a  means  for  true 
comparisons  of  naval  systems.  The  previous  chapters  provided  a  critical  analysis  of  the 
track  management  systems  within  the  Navy,  and  showed  that  KVA  is  a  valuable  tool  for 
determining  the  value  for  these  systems. 

3.  Can  ROK  be  Used  to  Determine  Areas  Where  Open  Architecture 
May  Provide  Increased  Efficiency? 

Increased  ROK  does  not,  in  and  of  itself,  constitute  improved  operational  value  of 
a  system  developed  using  an  OA  approach.  Analysis  of  ROK,  while  important,  only 
describes  the  relationship  between  inputs  to  output  for  each  of  the  core  process  within  a 
situational  awareness  system,  and  will  not  describe  where  future  efficiencies  or 
inefficiencies  might  be  obtained  through  process  reengineering.  Changes  in  ROK  should 
be  used  as  a  means  to  identify  processes  that  should  be  scrutinized  for  possible 
optimization  of  knowledge  assets.  When  ROK’s  are  derived  from  defensible  KVA  data, 
management  is  provided  a  tool  to  analyze  performance  metrics  for  knowledge  capital 
assets  within  the  organization,  and  can  make  more  informed  decisions  on  the  application 
of  knowledge  assets. 
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4,  Can  Real  Options  Analysis  be  Used  to  Support  Decisions  Regarding 
Functional  Integration  of  Current  Platforms  into  Future  Systems? 

The  ROK  results  from  the  application  of  the  KVA  methodology  to  core  processes 
provide  the  raw  data  that  is  used  to  determine  operational  options  for  systems  design  and 
implementation.  However,  without  the  accompanying  market  comparables,  it  would 
prove  insufficient  from  an  acquisitions  viewpoint,  as  the  financial  options  would  not  be 
monetized.  When  market  comparables  are  integrated  into  the  KVA  analysis  a  more 
robust  determination  can  be  made  regarding  functional  integration  for  future  systems 
from  both  an  operational  and  acquisitions  perspective.  From  a  strictly  operational 
standpoint,  the  most  prevalent  options  are  listed  below: 

•  Do  nothing  and  allow  the  “As  Is”  processes  to  continue. 

•  Create  and  apply  middleware  solutions  to  interface  between  systems  built 
under  an  open  architecture  framework  to  legacy  systems.  If  successful, 
look  to  expand  to  all  functional  aspects  of  AEGIS  and  SSDS  platforms. 

•  Acquire  COTS  hardware  to  replace  existing  legacy  components.  If 
successful,  look  to  continue  with  COTS  refresh  on  a  scheduled  basis. 

•  Completely  upgrade  AEGIS  and  SSDS  platforms  to  conform  to  OACE 
Category  4/5  compliance  levels.  If  successful,  apply  OA  to  all  future 
situational  awareness  systems  designs  and  implementations,  and  look  to 
expand  to  other  functional  areas. 

B.  RESEARCH  LIMITATIONS 

The  data  that  was  collected  and  analyzed  for  this  thesis  was  provided  by  subject 
matter  experts,  both  in  the  operational  and  training  environment.  Each  SME  brings 
different  experiences  and  levels  of  expertise  to  bear  on  their  knowledge  estimates 
provided  for  this  research.  The  data  cannot  be  assumed  perfect.  Until  automated  data 
capturing  methods  are  in  place,  and  historical  data  can  be  retrieved,  assessed  and 
analyzed,  SME’s  will  continue  to  be  the  focal  point  of  this  type  of  analysis. 

The  “To  Be”  analysis  was  based  on  situations  that  SME’s  determined  to  be  the 
best  areas  where  open  architecture  could  provide  value  to  the  operator.  While  process 
reengineering  ideas  were  constructed,  the  technical  and  legal  aspects  of  the  “To  Be” 
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analysis  were  avoided  in  order  to  provide  a  conceptual  idea  rather  than  a  practical  one. 
Application  of  current  legal  parameters,  technical  constraints  and  budgetary  limitations 
would  be  needed  in  order  to  form  a  more  practical  solution. 
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VI.  RECOMMENDATIONS 


This  thesis  explored  the  possibilities  for  using  KVA  as  a  methodology  to  measure 
the  operational  effectiveness  of  an  open  architecture  approach  to  systems  design. 
Looking  at  a  notional  reengineering  effort  founded  on  the  principles  of  open  architecture, 
as  laid  out  by  the  PEO  IWS,  Open  Architecture  Division,  there  are  definite  advantages  to 
be  gained  through  open  architecture  and  the  use  of  KVA  as  a  management  tool. 
Changing  the  underlying  way  that  systems  are  developed  and  implemented  is  a  huge 
undertaking  and  will  require  a  fundamental  change  in  the  way  the  Navy  conducts 
business.  The  Navy  has  begun  the  process  of  change  through  the  creation  of  the  OA 
Division  in  PEO  IWS.  This  first  step  was  vital  for  the  success  of  current  and  future  naval 
systems  in  the  area  of  interoperability  and  upgradeability,  but  additional  research  will  be 
necessary  to  facilitate  a  seamless  transition. 

A,  RECOMMENDED  CHANGE 

Realizing  the  value  of  an  open  architecture  approach  to  systems  design  will 
require  data  capturing  mechanisms  that  are  not  currently  available.  The  KVA  analysis, 
and  any  other  for  that  matter,  is  only  as  good  as  the  data  used  for  analysis.  Eor  a 
complete  analysis  of  OA,  the  following  recommendations  are  provided; 

•  Initiate  efforts  to  include  KVA  analysis  for  core  processes  within 
situational  awareness  systems. 

•  Define  core  processes  and  monitor  the  learning  time  and  work  time 
required  to  accomplish  these  processes.  As  the  data  becomes  more 
comprehensive,  the  results  will  better  reflect  actual  processes  as  they  are 
being  conducted. 

•  Create  and  update  a  repository  of  market  comparables  so  that  future 
financial  analysis  of  KVA  results  can  tap  into  a  historical  library  of 
commercial  sector  functions  that  could  match  the  process  being  analyzed. 

B,  FOLLOW-ON  RESEARCH 

With  the  foundation  being  laid,  there  is  still  much  research  required  in  the  area  of 
measuring  and  determining  the  value  of  open  architecture.  The  acquisition  community 
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could  especially  benefit  from  an  open  arehitecture  approaeh  to  systems  design,  through 
software  reuse,  sealability  and  interoperability.  For  this  community  to  embrace  the  tenets 
and  attributes  of  open  arehiteeture,  further  researeh  is  required. 

First,  market  eomparables  should  be  researehed  and  applied  to  the  results  of  any 
KVA  analysis.  This  thesis  focused  on  the  operational  value  of  an  open  arehiteeture,  but 
to  the  aequisition  eommunity  it  is  imperative  to  provide  a  surrogate  for  finaneial  returns. 
Market  comparables  provides  this  through  1)  a  eomparison  of  similar  proeesses  from  the 
eommereial  seetor;  2)  eomparing  this  proeess  with  the  comparable  non-profit  or 
governmental  proeess  being  analyzed;  3)  determining  the  revenue  assoeiated  with  the 
commercial  process;  4)  applying  the  revenue  estimates  to  the  non-profit  or  governmental 
proeess  to  determine  what  priee  (revenue)  the  eommereial  sector  is  getting  for  similar 
proeess  outputs.  This  type  of  researeh  will  be  vital  for  the  continued  movement  of  OA 
into  the  mainstream  aequisition  community  due  to  the  faet  that  KVA  analysis  can  be 
monetized.  Having  a  means  to  see  a  finaneial  impact  on  the  design,  operation  and 
maintenance  of  an  OA  system  eould  prove  to  be  a  key  element  of  implementing  OA 
throughout  the  Navy’s  core  proeesses. 

Seeond,  an  analysis  on  the  maintainability  of  OA  systems  should  be  eondueted. 
This  area  should  prove  to  be  the  most  important  in  the  area  of  value  when  using  an  open 
arehitecture  approaeh  to  systems  design.  Through  its  ability  to  rapidly  seale,  upgrade  and 
modify,  a  system  founded  on  OA  prineiples  ean  have  the  potential  to  see  huge  savings  in 
maintainability.  Providing  an  analysis  in  this  area  could  provide  an  important  rationale 
for  the  eontinued  use  of  open  arehiteeture.  Providing  a  KVA  and  market  eomparables 
analysis  on  the  maintainability  of  systems  ereated  through  an  OA  framework  is  the  next 
step  in  providing  a  well-rounded  analysis  of  OA. 

Lastly,  a  KVA  analysis  of  the  entire  AEGIS  and  SSDS  systems  eould  provide 
insight  into  areas  that  would  not  be  fully  realized  through  an  analysis  of  only  one 
component  of  the  systems  in  a  process.  This  thesis  examined  the  area  of  traek 
management,  but  that  is  only  one  facet  of  the  overall  systems  aboard  naval  vessels. 
Command  and  control,  decision  support,  sensor  inputs  and  a  myriad  of  other  eomponents 
that  comprise  the  overall  systems  on  naval  ships  should  be  analyzed  concurrently  so  that 
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possible  benefits,  whieh  may  have  gone  unnotieed  when  foeusing  on  one  component,  can 
be  realized.  When  systems  are  examined  through  a  complete  analysis,  interface  and 
interoperability  issues  can  be  discerned  and  addressed. 
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